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

[Morten Brørup]

> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jeff Guo
> Sent: Friday, August 28, 2020 8:40 AM
> 
> 
> On 8/28/2020 10:06 AM, Wang, Haiyue wrote:
> >> -----Original Message-----
> >> From: dev <dev-bounces at dpdk.org> On Behalf Of Morten Brørup
> >> Sent: Thursday, August 27, 2020 20:38
> >> To: Guo, Jia <jia.guo at intel.com>; Yang, Qiming
> <qiming.yang at intel.com>; Xing, Beilei
> >> <beilei.xing at intel.com>; Zhao1, Wei <wei.zhao1 at intel.com>; Zhang, Qi
> Z <qi.z.zhang at intel.com>; Wu,
> >> Jingjing <jingjing.wu at intel.com>
> >> Cc: Richardson, Bruce <bruce.richardson at intel.com>; dev at dpdk.org;
> Zhang, Helin <helin.zhang at intel.com>;
> >> Yigit, Ferruh <ferruh.yigit at intel.com>; barbette at kth.se
> >> Subject: Re: [dpdk-dev] [PATCH v2 0/5] maximize vector rx burst for
> PMDs
> >>
> >>> From: Jeff Guo [mailto:jia.guo at intel.com]
> >>> Sent: Thursday, August 27, 2020 12:10 PM
> >>>
> >>> The limitation of burst size in vector rx was removed, since it
> should
> >>> retrieve as much received packets as possible. And also the
> scattered
> >>> receive path should use a wrapper function to achieve the goal of
> >>> burst maximizing.
> >>>
> >>> This patch set aims to maximize vector rx burst for for
> >>> ixgbe/i40e/ice/iavf/fm10k PMDs.
> >>>
> >>> v2->v1:
> >>> 1:add fm10k driver case
> >>> 2:refine some doc
> >>>
> >> I now noticed that the vector functions also does:
> >> nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_I40E_DESCS_PER_LOOP);
> >>
> >> 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.
> >
> >> That is, unless the rte_eth_rx_burst() API is extended with
> requirements to nb_pkts, as discussed in
> >> the other thread:
> >> http://inbox.dpdk.org/dev/20200827114117.GD569@bricha3-
> >> MOBL.ger.corp.intel.com/T/#mc8051e9022d6aeb20c51c5a226b2274d3d6d4266
> 
> 
> Agree with above haiyue said, and go through the discuss on the thread,
> i think vector path was born definitely for the spirit of dpdk, each
> driver could keep the performance base on
> 
> the instinct requirement and define what is the specific "max", the
> path
> option could give to app, it could static choose one when set up queue
> or dynamic but not the driver scope,
> 
> document could be add to AVI if need for benefit user.
> 

Based on the discussion in the other thread, I think a minimum requirement to nb_pkts will be accepted.

On that note, for the series:

Acked-by: Morten Brørup <mb at smartsharesystems.com>