> -----Original Message----- > From: Ferruh Yigit <ferruh.yi...@xilinx.com> > Sent: Tuesday, September 13, 2022 3:01 PM > To: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>; Hanumanth Reddy > Pothula <hpoth...@marvell.com>; Thomas Monjalon <tho...@monjalon.net> > Cc: dev@dpdk.org; xuan.d...@intel.com; wenxuanx...@intel.com; > xiaoyun...@intel.com; step...@networkplumber.org; yuanx.w...@intel.com; > m...@ashroe.eu; yuying.zh...@intel.com; qi.z.zh...@intel.com; > viachesl...@nvidia.com; Jerin Jacob Kollanukkaran <jer...@marvell.com>; > Nithin Kumar Dabilpuram <ndabilpu...@marvell.com> > Subject: [EXT] Re: [PATCH v3 1/3] ethdev: introduce pool sort capability > > External Email > > ---------------------------------------------------------------------- > On 9/13/2022 9:06 AM, Andrew Rybchenko wrote: > > On 9/2/22 10:00, Hanumanth Pothula wrote: > >> This patch adds support for the pool sort capability. > > > > "Add support for serveral (?) mbuf pools per Rx queue." > > > > I dislike the word "sort" in summary and the feature description. IMHO > > it is too restrictive for intended behaviour. > > > > The key feature here is just support for more than one mbuf pool per > > Rx queue. That's it. Everything else should be out of scope of the > > definiteion. > > > > ack, and author already agreed to update it as 'MULTIPLE_POOL', perhaps > should we say 'MULTIPLE_MEMPOOL' ?
Yes, will take care naming. > > > If buffers from many pools are provided, the hardware may do whatever > > it wants with it. Use smaller buffers for small packets and bigger for > > big. Use bigger buffers for small packets if there is no small buffers > > available. Use big plus small buffer if Rx scatter is enabled and a > > packet fits in such combination. And so so on. > > > > I.e. the feature should be orthogoal to Rx scatter. > > Rx scatter just says if driver/application allows to chain mbufs to > > receive a packet. If Rx scatter is disabled, a packet must be > > delivered in a single mbuf (either big or small). If Rx scatter is > > enable, a packet may be delivered using a chain of mbufs obtained from > > provided pools (either just one or many if several pools are > > supported). > > > > Ideally the feature should be orthogonal to buffer split as well. I.e. > > provide many pools for different segments. > > May be it is an overkill to provide pools A and B for the first > > segment and C and D for the second. It could be limitted to the last > > segment only. If so, we need separate strcture (not > > rte_eth_rxseg) to pass many pools. IMHO, an array of mempools is > > sufficient - similar to Rx queue configuration. > > I.e. no extra length since data length may be derived from mempool > > element size. Thanks Andrew for your valuable inputs. Yes, an array of mempools works fine. Will upload V4 by taking care above. > > > >> Some of the HW has support for choosing memory pools based on the > >> packet's size. The pool sort capability allows PMD to choose a memory > >> pool based on the packet's length. > >> > >> This is often useful for saving the memory where the application can > >> create a different pool to steer the specific size of the packet, > >> thus enabling effective use of memory. > >> > >> For example, let's say HW has a capability of three pools, > >> - pool-1 size is 2K > >> - pool-2 size is > 2K and < 4K > >> - pool-3 size is > 4K > >> Here, > >> pool-1 can accommodate packets with sizes < 2K > >> pool-2 can accommodate packets with sizes > 2K and < 4K > >> pool-3 can accommodate packets with sizes > 4K > >> > >> With pool sort capability enabled in SW, an application may create > >> three pools of different sizes and send them to PMD. Allowing PMD to > >> program HW based on packet lengths. So that packets with less than 2K > >> are received on pool-1, packets with lengths between 2K and 4K are > >> received on pool-2 and finally packets greater than 4K are received > >> on pool-3. > >> > >> The following two capabilities are added to the rte_eth_rxseg_capa > >> structure, 1. pool_sort --> tells pool sort capability is supported > >> by HW. > >> 2. max_npool --> max number of pools supported by HW. > >> > >> Defined new structure rte_eth_rxseg_sort, to be used only when pool > >> sort capability is present. If required this may be extended further > >> to support more configurations. > >> > >> Signed-off-by: Hanumanth Pothula <hpoth...@marvell.com> > >> > >> v3: > >> - Implemented Pool Sort capability as new Rx offload capability, > >> RTE_ETH_RX_OFFLOAD_BUFFER_SORT. > >> v2: > >> - Along with spec changes, uploading testpmd and driver changes. > >> --- > > > > [snip] > >
