Re: [PATCH v7] ethdev: add special flags when creating async transfer table

[Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>]

On 1/17/23 18:13, Ferruh Yigit wrote:
> On 11/14/2022 11:59 AM, Rongwei Liu wrote:
>> In case flow rules match only one kind of traffic in a flow table,
>> then optimization can be done via allocation of this table.
>> Such optimization is possible only if the application gives a hint
>> about its usage of the table during initial configuration.
>>
>> The transfer domain rules may process traffic from wire or vport,
>> which may correspond to two kinds of underlayer resources.
>> That's why the first two hints introduced in this patch are about
>> wire and vport traffic specialization.
>> Wire means traffic arrives from the uplink port while vport means
>> traffic initiated from VF/SF.
>>
>> There are two possible approaches for providing the hints.
>> Using IPv4 as an example:
>> 1. Use pattern item in both template table and flow rules.
>>
>>     pattern_template: pattern ANY_VPORT / eth / ipv4 is 1.1.1.1 / end
>>     async flow create: pattern ANY_VPORT / eth / ipv4 is 1.1.1.2 / end
>>
>>     "ANY_VPORT" needs to be present in each flow rule even if it's
>>     just a hint. No value to match because matching is already done by
>>     IPv4 item.
>>
>> 2. Add special flags into table_attr.
>>
>>     template_table 0 create table_id 0 group 1 transfer vport_orig
>>
>> Approach 1 needs to specify the pattern in each flow rule which wastes
>> memory and is not user friendly.
>> This patch takes the 2nd approach and introduces one new member
>> "specialize" into rte_flow_table_attr to indicate possible flow table
>> optimization.
>>
>> By default, there is no hint, so the behavior of the transfer domain
>> doesn't change.
>> There is no guarantee that the hint will be used by the PMD.
>>
>> Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
>> Acked-by: Ori Kam <orika@nvidia.com>
> 
> Hi Andrew, Ivan,
> 
> Do you have objection/comment to latest version, if not I will proceed
> with patch?
> 
> Thanks,
> ferruh

Hi Ferruh,

Sorry, but I'm still unhappy with the description.
See my reply.

Thanks,
Andrew.