> -----Original Message----- > From: Ananyev, Konstantin <konstantin.anan...@intel.com> > Sent: Monday, October 12, 2020 18:56 > To: Slava Ovsiienko <viachesl...@nvidia.com>; NBU-Contact-Thomas > Monjalon <tho...@monjalon.net>; Andrew Rybchenko > <andrew.rybche...@oktetlabs.ru>; Yigit, Ferruh <ferruh.yi...@intel.com> > Cc: dev@dpdk.org; step...@networkplumber.org; Shahaf Shuler > <shah...@nvidia.com>; olivier.m...@6wind.com; jerinjac...@gmail.com; > maxime.coque...@redhat.com; david.march...@redhat.com; Asaf Penso > <as...@nvidia.com> > Subject: RE: [dpdk-dev] [RFC] ethdev: introduce Rx buffer split > > > > > > > -----Original Message----- > > > From: Ananyev, Konstantin <konstantin.anan...@intel.com> > > > Sent: Monday, October 12, 2020 18:28 > > > To: NBU-Contact-Thomas Monjalon <tho...@monjalon.net>; Andrew > > > Rybchenko <andrew.rybche...@oktetlabs.ru>; Yigit, Ferruh > > > <ferruh.yi...@intel.com>; Slava Ovsiienko <viachesl...@nvidia.com> > > > Cc: dev@dpdk.org; step...@networkplumber.org; Shahaf Shuler > > > <shah...@nvidia.com>; olivier.m...@6wind.com; > jerinjac...@gmail.com; > > > maxime.coque...@redhat.com; david.march...@redhat.com; Asaf > Penso > > > <as...@nvidia.com> > > > Subject: RE: [dpdk-dev] [RFC] ethdev: introduce Rx buffer split > > > > > > > > > > > > > > > > > 12/10/2020 11:56, Slava Ovsiienko: > > > > > Hi, Andrew > > > > > > > > > > Thank you for the comments. > > > > > > > > > > We have two approaches how to specify multiple segments to split > > > > > Rx > > > packets: > > > > > 1. update queue configuration structure 2. introduce new > > > > > rx_queue_setup_ex() routine with extra parameters. > > > > > > > > > > For [1] my only actual dislike is that we would have multiple > > > > > places to specify the pool - in rx_queue_setup() and in the > > > > > config structure. So, we should implement some checking (if we > > > > > have offload flag set we should check whether mp parameter is > > > > > NULL and segment descriptions array pointer/size is provided, if > > > > > no offload flag set - we must > > > check the description array is empty). > > > > > > > > > > > @Thomas, @Ferruh: I'd like to hear what other ethdev > > > > > > maintainers think about it. > > > > > > > > > > Yes, it would be very nice to hear extra opinions. Do we think > > > > > the providing of extra API function is worse than extending > > > > > existing structure, introducing some conditional ambiguity and > > > > > complicating the parameter compliance check? > > > > > > > > Let's try listing pros and cons of each approach, so we can conclude. > > > > > > > > 1/ update queue config struct > > > > > > > > 1.1 pro: keep same queue setup function > > > > 1.2 con: two mempool pointers (struct or function) > > > > 1.3 con: variable size of segment description array > > > > > > > > 2/ new queue setup function > > > > > > > > 2.1 con: two functions for queue setup > > > > 2.2 pro: mempool pointer is not redundant > > > > 2.3 pro: segment description array size defined by the caller > > > > > > > > What else I'm missing? > > > > > > > > > > My 2 cents: can we make new (_ex) function to work for both original > > > config > > > (1 mp for all sizes, no split) and for new config (multiple mp, split > allowed)? > > > Then in future (21.11?) we can either get rid of original one, or > > > even make it a wrapper around all one? > > > Konstantin > > > > Yes, actually the mlx5 PMD implementation follows this approach - > > specifying the segment description array with the only element and > > zero size/offset provides exactly the same configuration as existing > > rte_eth_rx_queue_setup(). > > > > Currently I'm detailing the description (how HEAD_ROOM is handled, > > what happens if array is shorter the the buffer chain for segment of > > maximal size, the zero segment size means follow the value deduced from > the pool and so on). > > > > So, may we consider this point as one more "pro" to setup_ex approach > > ? 😊 > > > > From my perspective, yes. > It is sort of more gradual approach. > I expect it would be experimental function for some time, so we'll have time > to try it, adjust, fix, etc without breaking original one. > Thank you for providing your opinion (whatever). Yes, function will be marked as experimental.
With best regards, Slava
