> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Bruce Richardson > Sent: Friday, August 28, 2020 12:07 PM > > On Fri, Aug 28, 2020 at 11:03:59AM +0200, Morten Brørup wrote: > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Bruce > Richardson > > > > <snip> > > > > > > Right. For now then, it seems like just documenting a minimum burst > > > size is > > > reasonable. > > > > I agree. It is so far from the spirit of DPDK to call > rte_eth_rx_burst() with a small nb_pkts that the driver developers > didn't even consider it. The API documentation needs fixing, not the > drivers. > > > > It doesn't take care of your example 4 packet latency sensitive > application, though. Which BTW also doesn’t work today on drivers with > vector support. So it might not be a real world scenario anyway. :-) > > > AFAIK, 8 is the smallest burst guaranteed to work everywhere, but I > think > just about everything bar the AVX2 i40e code path also supports 4 as a > burst size. Therefore adjusting to 4 as min-burst might well be > reasonable. > > /Bruce
There must be a reason the i40e AVX2 driver chose to step up to 8 from the previous convention of 4. Considering Intel's stance on the controversial vector instructions, a larger numbers seems more future proof. HPC benefits from the vector instructions, and DPDK seems to benefit from them too. Let's not prevent that. Since I don't have insight into Intel's (or any other CPU vendors') plans for future vector instructions, I will assume that 8 suffices for the foreseeable future, and thus I am leaning towards 8 rather than 4. -Morten
