18/01/2023 08:28, Andrew Rybchenko: > On 11/14/22 14:59, 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. > > The above description is misleading. It alternates options (1) > and (2), but in fact (2) requires (1) as well.
Yes the above description may be misleading and it seems you are misleaded :) I will explain below why the option (2) doesn't require (1). I think we should apply the same example to both cases to make it clear: 1. Use pattern item in both template table and flow rules: template table 3 = transfer pattern ANY_VPORT / eth / ipv4 src is 255.255.255.255 / end flow rule = template_table 3 pattern ANY_VPORT / eth / ipv4 src is 1.1.1.1 / end The pattern template 3 will be used only to match flows coming from vports. ANY_VPORT needs to be present in each flow rule. ANY_VPORT matching is redundant with IP src 1.1.1.1 because the user knows 1.1.1.1 is the IP of a vport. 2. Add specialization flag into template table attribute: template table 3 = transfer VPORT_ORIG pattern eth / ipv4 src is 255.255.255.255 / end flow rule = template_table 3 pattern eth / ipv4 src is 1.1.1.1 / end The pattern template 3 can be used only to match flows coming from vports. > (2) is simply done on different level - much earlier, before > flow rules creation. Since resources allocation is assumed to > be done on table creation, we need to know the purpose of the > table in advance to optimize resources allocation. Actually in both cases we get the hint at template table creation. But in solution 2 we are not creating a redundant pattern matching, and we don't need to check it in flow rules, so it is more efficient. > Since (2) is *not a matching criteria*, but just a hint, (1) > flow rules must have matching criteria anyway. No we don't need the matching criteria ANY_VPORT with solution (2) because we are already matching on an IP src which is a vport. > > +Table Attribute: Specialize > > +^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > + > > +Application can help optimizing underlayer resources and insertion rate > > +by specializing template table. > > +Specialization is done by providing hints > > +in the template table attribute ``specialize``. > > + > > +This attribute is not mandatory for each PMD to implement. > > +If a hint is not supported, it will be silently ignored, > > +and no special optimization is done. > > + > > +If a table is specialized, the application should make sure the rules > > +comply with the table attribute. > > If a table is specialized, the application must make sure that > all flow rules added to the table have pattern which implies > corresponding matching criteria. For example if a table is > specialized to be wire-origin only, pattern should have > represented port item with ethdev which corresponds to a > physical port (or any other item which matches packets > coming from wire only). No need of a matching criteria strictly mapping the hint. Here the hint is SPECIALIZE_TRANSFER_VPORT_ORIG and the rules can match on an IP src which is assigned to a vport. So there is no need to strictly match the vport itself in the rule. Hope it make thinks clear. We can improve the commit log as I wrote above.
