> -----Original Message----- > From: Stephen Hemminger <step...@networkplumber.org> > Sent: Saturday, August 29, 2020 04:31 > To: Guo, Jia <jia....@intel.com> > Cc: Wang, Haiyue <haiyue.w...@intel.com>; Morten Brørup > <m...@smartsharesystems.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>; > 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 > > On Fri, 28 Aug 2020 14:39:33 +0800 > Jeff Guo <jia....@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.
I think if people care about performance, then PMDs have done every possible methods like the burst size, then no need to invent their burst handers. ;-) At least, burst size is an optimize hit for performance.
