17/02/2022 15:16, Ori Kam:
> From: Ori Kam
> > From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>
> > > On 2/16/22 17:53, Ori Kam wrote:
> > > > From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>
> > > >> On 2/12/22 05:19, Alexander Kozyrev wrote:
> > > >>> On Fri, Feb 11, 2022 7:42 Andrew Rybchenko 
> > > >>> <andrew.rybche...@oktetlabs.ru>:
> > > >>>>> +/**
> > > >>>>> + * @warning
> > > >>>>> + * @b EXPERIMENTAL: this API may change without prior notice.
> > > >>>>> + *
> > > >>>>> + * Queue operation attributes.
> > > >>>>> + */
> > > >>>>> +struct rte_flow_q_ops_attr {
> > > >>>>> +   /**
> > > >>>>> +    * The user data that will be returned on the completion events.
> > > >>>>> +    */
> > > >>>>> +   void *user_data;
> > > >>>>
> > > >>>> IMHO it must not be hiddne in attrs. It is a key information
> > > >>>> which is used to understand the opration result. It should
> > > >>>> be passed separately.
> > > >>>
> > > >>> Maybe, on the other hand it is optional and may not be needed by an 
> > > >>> application.
> > > >>
> > > >> I don't understand how it is possible. Without it application
> > > >> don't know fate of its requests.
> > > >>
> > > > IMHO since user_data should be in all related operations API
> > > > along with the attr, splitting the user_data will just add extra 
> > > > parameter
> > > > to each function call. Since we have number of functions and will add
> > > > more in future I think it will be best to keep it in this location.
> > >
> > > My problem with hiding user_data inside attr is that
> > > 'user_data' is not an auxiliary attribute defining extra
> > > properties of the request. It is a key information.
> > > May be attr is not an ideal name for such grouping
> > > of parameters. Unfortunately I have no better ideas right now.
> > >
> > I understand your point, if you don't have objections lets keep the current 
> > one
> > and if needed we will modify.
> > Is that O.K?
> 
> Thinking about it again,
> lets move it to a dedecated parameter.

I'm OK with the decision of moving user_data as a function parameter.


Reply via email to