Hello, On Mon, Jan 26, 2015 at 8:08 PM, Stephen Hemminger < stephen at networkplumber.org> wrote:
> On Mon, 26 Jan 2015 13:17:48 +0300 > Alexander Belyakov <abelyako at gmail.com> wrote: > > > 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) > > Did you try using git bisect to identify the problem. > I believe dpdk-1.6.0r2 is the first release with bypass adapter (device id 155d) support and it already has the issue. So it seems I have no "good" point. Alexander
