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 <rongw...@nvidia.com> > Acked-by: Ori Kam <or...@nvidia.com>
Hi Andrew, Ivan, Do you have objection/comment to latest version, if not I will proceed with patch? Thanks, ferruh
