> From: dev [mailto:dev-boun...@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-boun...@dpdk.org> On Behalf Of Morten Brørup > >> Sent: Thursday, August 27, 2020 20:38 > >> To: Guo, Jia <jia....@intel.com>; Yang, Qiming > <qiming.y...@intel.com>; Xing, Beilei > >> <beilei.x...@intel.com>; Zhao1, Wei <wei.zh...@intel.com>; Zhang, Qi > Z <qi.z.zh...@intel.com>; Wu, > >> Jingjing <jingjing...@intel.com> > >> Cc: Richardson, Bruce <bruce.richard...@intel.com>; dev@dpdk.org; > Zhang, Helin <helin.zh...@intel.com>; > >> Yigit, Ferruh <ferruh.yi...@intel.com>; barbe...@kth.se > >> Subject: Re: [dpdk-dev] [PATCH v2 0/5] maximize vector rx burst for > PMDs > >> > >>> From: Jeff Guo [mailto:jia....@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 <m...@smartsharesystems.com>
