[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