Re: [dpdk-dev] [PATCH v5 3/4] vhost: support async dequeue for split ring

["Hu, Jiayu" <jiayu.hu@intel.com>]

> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Friday, July 16, 2021 9:53 PM
> To: Hu, Jiayu <jiayu.hu@intel.com>
> Cc: Maxime Coquelin <maxime.coquelin@redhat.com>; Ma, WenwuX
> <wenwux.ma@intel.com>; dev@dpdk.org; Xia, Chenbo
> <chenbo.xia@intel.com>; Jiang, Cheng1 <cheng1.jiang@intel.com>; Wang,
> YuanX <yuanx.wang@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v5 3/4] vhost: support async dequeue for
> split ring
> 
> On Fri, Jul 16, 2021 at 3:45 PM Hu, Jiayu <jiayu.hu@intel.com> wrote:
> > > - I don't like this threshold, this is too low level and most users
> > > will only see the shiny aspect "better performance" without
> > > understanding the consequences.
> > > By default, it leaves the door open to a _bad_ behavior, that is
> > > packet reordering.
> > > At a very minimum, strongly recommend to use 0 in the API.
> >
> > That's a good point. But there are some reasons of open this value to users:
> > - large packets will block small packets, like control packets of TCP.
> > - dma efficiency. We usually see 20~30% drops because of offloading
> > 64B copies to dma engine.
> > - the threshold is not only related to hardware, but also application.
> > The value decides which copies are assigned to which worker, the CPU
> > or the DMA. As async vhost works in an asynchronous way, the threshold
> > value decides how many works can be done in parallel. It's not only
> > about what DMA engine and what platform we use, but also what
> computation the CPU has been assigned. Different users will have different
> values.
> >
> > I totally understand the worry about reordering. But simple iperf
> > tests show positive results with setting threshold in our lab. We need
> > more careful tests before modifying it, IMHO.
> 
> If you need more time, then please take it.
> The dma generic API could have an impact on this feature too.
> 
> Why the rush for merging this now?

Changing threshold or not is under discussion. No data shows setting
it to 0 is better than current design. On the contrary, our intensive lab
data shows positive results with this design. Please don't mix it with this
deq feature. Especially for now, app can set it to 0, if reordering really
matters a lot.
> 
> 
> --
> David Marchand