[dpdk-dev] [PATCH v2 0/5] maximize vector rx burst for PMDs

[Stephen Hemminger]

On Fri, 28 Aug 2020 14:39:33 +0800
Jeff Guo <jia.guo at intel.com> wrote:

> >> I am not sure about this, but if I read it correctly, calling rte_eth_rx_burst() with nb_pkts = 33
> >> (not 32) would only return 32 packets, even if more packets are available. (I assume that
> >> RTE_I40E_DESCS_PER_LOOP is 32.) In this case, I guess that you need to read the remaining of the
> >> requested packets using the non-vector function in order to support any nb_pkts value.
> >>  
> > This is vector instruction handling design requirement, like for avx2: #define ICE_DESCS_PER_LOOP_AVX 8,
> > if deep into the real loop handling, you will get the point why doing RTE_ALIGN_FLOOR. ;-)
> >
> > _ice_recv_raw_pkts_vec_avx2:
> > for (i = 0, received = 0; i < nb_pkts; i += ICE_DESCS_PER_LOOP_AVX, rxdp += ICE_DESCS_PER_LOOP_AVX)
> >
> > Maybe it is worth to tell PMD to stop using vector by calling rte_eth_rx_queue_setup with the application
> > burst size it wants.

There is no need for yet another nerd knob in DPDK.

The driver must accept any burst size > 0.
If it wants to optimize for certain multiples, then it can do so in its burst handler.
Like any optimized checksum calculator does.

Let the CPU branch predictor do its job and find the best path through the
driver code.

Something like:

uint16_t
my_driver_recv_burst((void *prxq, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
{
	if (nb_pkts == 32)
		return my_driver_recv_burst32(prxq, rx_pkts, nb_pkts);
	...
	else
		return my_driver_recv_burstN(prxq, rx_pkts, nb_pkts);
	...

}

You could repeatedly call the burst32 if passed large nb_pkts.