DPDK patches and discussions
 help / color / mirror / Atom feed
From: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
To: Alexander Belyakov <abelyako@gmail.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] DPDK testpmd forwarding performace degradation
Date: Mon, 26 Jan 2015 14:22:24 +0000	[thread overview]
Message-ID: <E115CCD9D858EF4F90C690B0DCB4D8972724E731@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <CAAQJX_Q_eMAG5Raj9yeeg_veGyZVd63A9MWJpq8jYLTOZBonzA@mail.gmail.com>

Hi Alexander,

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Alexander Belyakov
> Sent: Monday, January 26, 2015 10:18 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] DPDK testpmd forwarding performace degradation
> 
> 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?

I cannot reproduce the issue using two ports on two different 82599EB NICs, using 1.7.1 and 1.8.0.
I always get either same or better linerate as I increase the packet size.
Actually, have you tried using 1.8.0? 

Pablo
> 
> Regards,
> Alexander Belyakov

  reply	other threads:[~2015-01-26 14:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-26 10:17 Alexander Belyakov
2015-01-26 14:22 ` De Lara Guarch, Pablo [this message]
     [not found]   ` <CAAQJX_RueTvfr7UnANbLSKceerkfs5DZNguKdPhSVVn9OCGtrw@mail.gmail.com>
2015-01-27  7:51     ` [dpdk-dev] Fwd: " Alexander Belyakov
2015-01-27 10:14       ` [dpdk-dev] " Alexander Belyakov
2015-01-27 16:21         ` De Lara Guarch, Pablo
2015-01-28 12:24           ` Alexander Belyakov
2015-01-29 12:43             ` Alexander Belyakov
2015-02-05 14:39               ` Alexander Belyakov
2015-01-26 17:08 ` Stephen Hemminger
     [not found]   ` <CAAQJX_QN+HWS7k+MMw+NC3UnSKcdr-B=L1nLdOCh1br5eiYD+A@mail.gmail.com>
2015-01-27  7:51     ` [dpdk-dev] Fwd: " Alexander Belyakov
2015-01-27  2:49 [dpdk-dev] " 吴亚东
2015-01-27  8:04 ` Alexander Belyakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E115CCD9D858EF4F90C690B0DCB4D8972724E731@IRSMSX108.ger.corp.intel.com \
    --to=pablo.de.lara.guarch@intel.com \
    --cc=abelyako@gmail.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).