> -----Original Message----- > From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru> > Sent: Thursday, October 15, 2020 16:07 > To: NBU-Contact-Thomas Monjalon <tho...@monjalon.net>; Ferruh Yigit > <ferruh.yi...@intel.com>; Jerin Jacob <jerinjac...@gmail.com>; Slava > Ovsiienko <viachesl...@nvidia.com>; Andrew Rybchenko > <arybche...@solarflare.com> > Cc: dpdk-dev <dev@dpdk.org>; Stephen Hemminger > <step...@networkplumber.org>; Olivier Matz <olivier.m...@6wind.com>; > Maxime Coquelin <maxime.coque...@redhat.com>; David Marchand > <david.march...@redhat.com> > Subject: Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split > > On 10/15/20 3:49 PM, Thomas Monjalon wrote: > > 15/10/2020 13:49, Slava Ovsiienko: > >> From: Ferruh Yigit <ferruh.yi...@intel.com> > >>> On 10/15/2020 12:26 PM, Jerin Jacob wrote: > >>> > >>> <...> > >>> > >>>>>>>> If we see some of the features of such kind or other PMDs > >>>>>>>> adopts the split feature - we'll try to find the common root > >>>>>>>> and consider the way how > >>>>>> to report it. > >>>>>>> > >>>>>>> My only concern with that approach will be ABI break again if > >>>>>>> something needs to exposed over rte_eth_dev_info(). > >>>>> > >>>>> Let's reserve the pointer to struct rte_eth_rxseg_limitations in > >>>>> the rte_eth_dev_info to avoid ABI break? > >>>> > >>>> Works for me. If we add an additional reserved field. > >>>> > >>>> Due to RC1 time constraint, I am OK to leave it as a reserved filed > >>>> and fill meat when it is required if other ethdev maintainers are OK. > >>>> I will be required for feature complete. > >>>> > >>> > >>> Sounds good to me. > > > > OK for me. > > OK as well, but I dislike the idea with pointer in dev_info. > It sounds like it breaks existing practice.
Moreover, if we are going to have multiple features using Rx segmentation we should provide multiple structures with limitations - at least, one per feature. > We should either reserve enough space or simply add dedicated API call to > report Rx seg capabilities. > It seems we are trying to embrace everything in very generic way 😊 Just curious - how did we managed to survive without limitations on Tx direction? No one told us how many segments PMD supports on Tx, what is the limitations for offsets and alignments, it seems there is no limits for tx segment size at all. How could it happen? Tx limitations do not exist? Just no one cared about the Tx limitations? As for Rx limitations - there are no reasonable ones for now. We'll invent the way to report the limitations (and it seems to be unbalanced - we should provide the same to Tx), the next step is to provide at least one PMD using that, and in this way to make mlx5 PMD to report silly values - "I have no reasonable limitations beyond meaningful buffer size under pool_buf_size/UINT16_MAX)". IMO, If some HW does not support arbitrary split (suppose, it is not common case, most of HW is very flexible about specifying Rx buffers) the BUFFER_SPLIT feature should not be advertised at all, because it would be not very useful - application is intended to work over specific protocol, it knows where it wants to set split point (defined by packet format). Hence, application is not so interested about offsets, alignments, etc - it just checks whether PMD provides requested split points or not. That's why just simple documenting was initially intended, there are just no a lot of limitations expected, likewise Tx direction shows that. Yes, generally speaking, there are no doubts it would be nice to report the limitations, but: - not expected to have many (documenting can the few exceptions) - no nice way is found how to report - pointer? API? - complicated to present for various features (variable size array, multiple features) - not known which limitations are actually needed, just some theoretical ones So, we see the large white area, should we invent something not well-defined to cover one, or let's wait for actual request to check limitations that can't be handled by documenting and internal PMD checking/validation? With best regards, Slava
