[PATCH v7] ethdev: add special flags when creating async transfer table
Ferruh Yigit
ferruh.yigit at amd.com
Tue Jan 17 16:13:58 CET 2023
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 at nvidia.com>
> Acked-by: Ori Kam <orika at nvidia.com>
Hi Andrew, Ivan,
Do you have objection/comment to latest version, if not I will proceed
with patch?
Thanks,
ferruh
More information about the dev
mailing list