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

[Andrew Rybchenko]

On 11/8/22 14:18, Thomas Monjalon wrote:
> 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've replied on v4.

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