[ovs-dev] [PATCH] netdev-dpdk: Change eth rx burst size.

Traynor, Kevin kevin.traynor at intel.com
Thu Apr 9 23:22:04 UTC 2015


> -----Original Message-----
> From: Pravin Shelar [mailto:pshelar at nicira.com]
> Sent: Thursday, April 9, 2015 10:50 PM
> To: Traynor, Kevin
> Cc: Daniele Di Proietto; dev at openvswitch.org
> Subject: Re: [ovs-dev] [PATCH] netdev-dpdk: Change eth rx burst size.
> 
> On Thu, Apr 9, 2015 at 2:36 PM, Traynor, Kevin <kevin.traynor at intel.com>
> wrote:
> >
> >> -----Original Message-----
> >> From: Pravin Shelar [mailto:pshelar at nicira.com]
> >> Sent: Thursday, April 9, 2015 9:10 PM
> >> To: Traynor, Kevin; Daniele Di Proietto
> >> Cc: dev at openvswitch.org
> >> Subject: Re: [ovs-dev] [PATCH] netdev-dpdk: Change eth rx burst size.
> >>
> >> On Wed, Apr 8, 2015 at 8:43 AM, Kevin Traynor <kevin.traynor at intel.com>
> >> wrote:
> >> > Change eth rx burst size from 192 to 32. This significantly
> >> > improves performance for packets that will be forwarded
> >> > through dpdkvhost ports, as the max dpdkvhost tx burst
> >> > size (32) will not be exceeded. There are negligible
> >> > effects in other scenarios.
> >> >
> >> > Signed-off-by: Kevin Traynor <kevin.traynor at intel.com>
> >>
> >> Daniele,
> >> You mentioned that you are going to fix the issue by handling
> >> different burst size of vhost devices. Do you have the fix?
> >
> > It wasn't clear in the commit message but just to clarify, the
> > dpdkvhost max burst size is set in the DPDK vhost library and if
> > we try and enqueue >32 packets only 32 will be enqueued. We can
> > add a back-off/retry but it will give better performance to
> > ensure that the vhost burst size is not exceeded.
> >
> 
> How about adding for loop in vhost_send() to handle burst of packets
> larger than 32?

Yeah, the DPDK sample app uses a backoff(small sleep)/retry loop but
you could put it in a busy loop too. I was planning to add some retry
code anyway as it's possible that you could get bursts of >32 from a
different interface, so it's good to handle this.

The virtqueues are of very limited size (128 packets I think), so they
are not ideally suited to bursty traffic which I guess is why DPDK have
set the max burst size to 32. Time the PMD spends waiting/retrying is
time it could be doing something else, so I think it is better to reduce
the burst size where possible. I haven't seen any advantage to the 192 eth
rx burst size in my testing as changing to 32 I get negligible difference
on phy2phy tests (~1%) and I get a 2x-3x performance boost for vhost
loopback tests, but perhaps there are some use cases where it is
advantageous?


More information about the dev mailing list