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

[Ferruh Yigit <ferruh.yigit@amd.com>]

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