From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 11983C41A for ; Mon, 27 Apr 2015 10:06:59 +0200 (CEST) Received: by wgso17 with SMTP id o17so107159008wgs.1 for ; Mon, 27 Apr 2015 01:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tfMNvDZGp8DcyIwyyLILrnbKhcu90jSpt8m8D51J3sI=; b=RYCVaU6weogZSbF51Rt3BE5BRN5cKd296QFzPycU2nFNxYk8z/Iv1625ZsSMvMSGlg 6vJskSkzCBqLnfFJh8lEq62R/CLhVZA+3/sfkvBXfXExpcgnSzAXcjCeiMLOk5Lptol+ nSIF6o5wTLP7/JNvoINoCRhY9UKm4AksVuaGFMkM9eof6SJyLDw0cyp4TTFLG5YfrZKG CuUJxLq//TAzmSy4j0C/16QtyT7Q/awo/USffLpFddhxMKmQsDGHSWhklA8dpN53+rxI RtN97gwTH/ZjvdRvr2Cl+xearE7SeczmNzDyAyH2yiRXcn5LY6kSuMxRPbJ+8yXCl6PB dZfQ== MIME-Version: 1.0 X-Received: by 10.180.106.195 with SMTP id gw3mr18375728wib.25.1430122018886; Mon, 27 Apr 2015 01:06:58 -0700 (PDT) Received: by 10.27.136.70 with HTTP; Mon, 27 Apr 2015 01:06:58 -0700 (PDT) In-Reply-To: <6DC6DE50-F94F-419C-98DF-3AD8DCD4F69D@net.in.tum.de> References: <6DC6DE50-F94F-419C-98DF-3AD8DCD4F69D@net.in.tum.de> Date: Mon, 27 Apr 2015 11:06:58 +0300 Message-ID: From: Pavel Odintsov To: Paul Emmerich Content-Type: text/plain; charset=UTF-8 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Performance regression in DPDK 1.8/2.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 08:06:59 -0000 Hello! I executed deep test of Paul's toolkit and could approve performance degradation in 2.0.0. On Sun, Apr 26, 2015 at 9:50 PM, Paul Emmerich wrote: > Hi, > > I'm working on a DPDK-based packet generator [1] and I recently tried to > upgrade from DPDK 1.7.1 to 2.0.0. > However, I noticed that DPDK 1.7.1 is about 25% faster than 2.0.0 for my use > case. > > So I ran some basic performance tests on the l2fwd example with DPDK 1.7.1, > 1.8.0 and 2.0.0. > I used an Intel Xeon E5-2620 v3 CPU clocked down to 1.2 GHz in order to > ensure that the CPU and not the network bandwidth is the bottleneck. > I configured l2fwd to forward between two interfaces of an X540 NIC using > only a single CPU core (-q2) and measured the following throughput under > full bidirectional load: > > > Version TP [Mpps] Cycles/Pkt > 1.7.1 18.84 84.925690021 > 1.8.0 16.78 95.351609058 > 2.0.0 16.40 97.56097561 > > DPDK 1.7.1 is about 15% faster in this scenario. The obvious suspect is the > new mbuf structure introduced in DPDK 1.8, so I profiled L1 cache misses: > > Version L1 miss ratio > 1.7.1 6.5% > 1.8.0 13.8% > 2.0.0 13.4% > > > FWIW the performance results with my packet generator on the same 1.2 GHz > CPU core are: > > Version TP [Mpps] L1 cache miss ratio > 1.7 11.77 4.3% > 2.0 9.5 8.4% > > > The discussion about the original patch [2] which introduced the new mbuf > structure addresses this potential performance degradation and mentions that > it is somehow mitigated. > It even claims a 20% *increase* in performance in a specific scenario. > However, that doesn't seem to be the case for both l2fwd and my packet > generator. > > Any ideas how to fix this? A 25% loss in throughput prevents me from > upgrading to DPDK 2.0.0. I need the new lcore features and the 40 GBit > driver updates, so I can't stay on 1.7.1 forever. > > Paul > > > [1] https://github.com/emmericp/MoonGen > [2] http://comments.gmane.org/gmane.comp.networking.dpdk.devel/5155 -- Sincerely yours, Pavel Odintsov