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

Andrew Rybchenko andrew.rybchenko at oktetlabs.ru
Tue Nov 8 10:35:00 CET 2022


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.

>> 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.
> 
> 



More information about the dev mailing list