Re: [PATCH v3] ethdev: add hint when creating async transfer table

[Thomas Monjalon <thomas@monjalon.net>]

08/11/2022 10:35, Andrew Rybchenko:
> On 11/8/22 12:19, Thomas Monjalon wrote:
> > 06/11/2022 11:02, Andrew Rybchenko:
> >> On 10/4/22 11:31, Andrew Rybchenko wrote:
> >>> On 9/28/22 12:24, Rongwei Liu wrote:
> >>>> The transfer domain rule is able to match traffic wire/vf
> >>>> origin and it means two directions' underlayer resource.
> >>>>
> >>>> In customer deployments, they usually match only one direction
> >>>> traffic in single flow table: either from wire or from vf.
> > 
> > Customer deployment is not an argument.
> > 
> >>>> Introduce one new member transfer_mode into rte_flow_template_table_attr
> >>>> to indicate the flow table direction property: from wire, from vf
> >>>> or bi-direction(default).
> > 
> > The origin is not a direction.
> > We should update this sentence.
> > 
> >>>> It helps to save underlayer memory also on insertion rate, and this
> >>>> new field doesn't expose any matching criteira.
> > 
> > Should be reworded.
> > 
> >>>> By default, the transfer domain is to match bi-direction traffic, and
> >>>> no behavior changed.
> > 
> > This sentence is confusing, it should be removed.
> > 
> >>>> 1. Match wire origin only
> >>>>      flow template_table 0 create group 0 priority 0 transfer wire_orig...
> >>>> 2. Match vf origin only
> >>>>      flow template_table 0 create group 0 priority 0 transfer vf_orig...
> > 
> > This testpmd example needs to be introduced with a sentence.
> > 
> >>> Since wire_orig and vf_orig are just optional hints and not
> >>> all PMDs are obliged to handle it, it does not impose any
> >>> matching criteria.
> > 
> > Yes
> > 
> >>> So, example above are misleading and you
> >>> need to add pattern items to highlight that corresponding rules
> >>> are really wire_orig or vf_orig.
> > 
> > This is template table creation, so I don't think there is more to add.
> > What do you have in mind?
> > 
> 
> Since origin is just a hint which does not impose any matching
> criteria it must be highlighted in example that corresponding
> rules must have some pattern items defining corresponding
> origin.

Yes we could talk about corresponding rules in the commit message.

What do you think of the explanations in the doc?

> >> I'm sorry, but I still don't see how it is addressed in v4.
> > 
> > I think the documentation in v4 is pretty clear.
> > Do you see something in the doc which is confusing?
> > The commit message needs rewording though.