13/10/2020 23:59, Ferruh Yigit: > On 10/12/2020 10:56 AM, Slava Ovsiienko wrote: > > 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? > > I think decision was given with the deprecation notice which already says > ``rte_eth_rxconf`` will be updated for this. > > With new API, we need to create a new dev_ops too, not sure about creating a > new > dev_ops for a single PMD.
You should not view it as a feature for a single PMD. Yes, as always, it starts with only one PMD implementing the API, but I really think this feature is generic and multiple NICs will be able to support this offload. > For the PMD that supports this feature will need two dev_ops that is fairly > close to each other, as Andrew mentioned this is a duplication. > > And from user perspective two setup functions with overlaps can be confusing. > > +1 to having single setup function but update the config, and I can see v5 > sent > this way, I will check it. > > > > Now I'm updating the existing version on the patch based on rx_queue_ex() > > and then could prepare the version for configuration structure, > > it is not a problem - approaches are very similar, we just should choose > > the most relevant one. > > > > With best regards, Slava
