From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by dpdk.org (Postfix) with ESMTP id 17D4C255 for ; Mon, 26 Jan 2015 11:17:55 +0100 (CET) Received: by mail-qa0-f52.google.com with SMTP id x12so6003492qac.11 for ; Mon, 26 Jan 2015 02:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=R1YCBjCFBHawRnGog+v2AgCcalpVhIFMHHxp48gxg5k=; b=WZmQeUyw4qwV65rVSfV9nuHnuzQFwXFOVGEzIiOdDVEam8M5NvFBQH1fZV7cPga8FH FAdvlE1C5r0YiVXhvefBcIfnxAsGpZ9EudKT0bCB5IYhmJijNph+UFSzDbbpqWy9hdHy XsaMUhMiKbt+FoJy2yR4b8nkzgI/dZM4dCdtb2Zbf5b8nA9q4LgLnHXfGmJYlcWSjjpb ogkh+xt18qT+BkrmlTup09kF3I3afGJtlLpWOhPjwYLqQSOiWN5TnS/hOve1J4h0NDZM bUaVC1VxlEK38dBQ8j4NhiKOWXgbhUfznKpegWWIFq48nu0gZ/YRmk0Ij6x6YqSt9vGM bQJw== MIME-Version: 1.0 X-Received: by 10.140.92.33 with SMTP id a30mr37722286qge.30.1422267468061; Mon, 26 Jan 2015 02:17:48 -0800 (PST) Received: by 10.140.93.51 with HTTP; Mon, 26 Jan 2015 02:17:48 -0800 (PST) Date: Mon, 26 Jan 2015 13:17:48 +0300 Message-ID: From: Alexander Belyakov To: "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] DPDK testpmd forwarding performace degradation 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, 26 Jan 2015 10:17:58 -0000 Hello, recently I have found a case of significant performance degradation for our application (built on top of DPDK, of course). Surprisingly, similar issue is easily reproduced with default testpmd. To show the case we need simple IPv4 UDP flood with variable UDP payload size. Saying "packet length" below I mean: Eth header length (14 bytes) + IPv4 header length (20 bytes) + UPD header length (8 bytes) + UDP payload length (variable) + CRC (4 bytes). Source IP addresses and ports are selected randomly for each packet. I have used DPDK with revisions 1.6.0r2 and 1.7.1. Both show the same issue. Follow "Quick start" guide (http://dpdk.org/doc/quick-start) to build and run testpmd. Enable testpmd forwarding ("start" command). Table below shows measured forwarding performance depending on packet length: No. -- UDP payload length (bytes) -- Packet length (bytes) -- Forwarding performance (Mpps) -- Expected theoretical performance (Mpps) 1. 0 -- 64 -- 14.8 -- 14.88 2. 34 -- 80 -- 12.4 -- 12.5 3. 35 -- 81 -- 6.2 -- 12.38 (!) 4. 40 -- 86 -- 6.6 -- 11.79 5. 49 -- 95 -- 7.6 -- 10.87 6. 50 -- 96 -- 10.7 -- 10.78 (!) 7. 60 -- 106 -- 9.4 -- 9.92 At line number 3 we have added 1 byte of UDP payload (comparing to previous line) and got forwarding performance halved! 6.2 Mpps against 12.38 Mpps of expected theoretical maximum for this packet size. That is the issue. Significant performance degradation exists up to 50 bytes of UDP payload (96 bytes packet length), where it jumps back to theoretical maximum. What is happening between 80 and 96 bytes packet length? This issue is stable and 100% reproducible. At this point I am not sure if it is DPDK or NIC issue. These tests have been performed on Intel(R) Eth Svr Bypass Adapter X520-LR2 (X520LR2BP). Is anyone aware of such strange behavior? Regards, Alexander Belyakov