On 2/1/23 14:22, Ori Kam wrote:
Hi
Please also see my previous mail.
-----Original Message-----
From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>
Sent: Wednesday, 1 February 2023 13:11
On 2/1/23 13:58, Thomas Monjalon wrote:
01/02/2023 11:17, Andrew Rybchenko:
On 1/18/23 19:18, Thomas Monjalon wrote:
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 :)
It is not my intention. If it is only my problem, I'm OK to
step back.
It's OK to explain and check everything is OK, no worries.
Thanks for reviewing.
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.
It looks like I lost something here. Why do we need to specify
it in each flow rule if the matching is already fixed in
template table?
I think that's how template tables are designed.
Ori, please could you point us to the relevant documentation?
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.
What should happen if a packet with src IP 1.1.1.1 comes from
the wire? Almost anything could come from network.
It a packet comes from a wired port AND
the PMD did an optimization based on this hint,
then the packet could be not matched.
So, the hint changes matching results and therefore becomes
a strange (extra) matching criteria under specific
circumstance. It sounds bad. So, good application must use
real (always) matching criteria when composing flow rules.
So, RTE flow API should provide a way to write a good
application without extra pain.
That's why I'm saying that (2) requires (1) anyway.
I'm sorry I don't see why.
Will be in reply to Thomas
This feature is about where to place the rule in the HW.
This feature can be useful for any HW that as different pipelines for ingress
and egress traffic. It can be used to save resources or if some actions can be
done
only on one direction then the PMD can allow them and not block the this rule.
It does not say that hint is not required at all.
It is still useful for resources usage optimization if
application knows how it is going to use particular table.
So we agree that the hint is good?
Acceptable since we need to optimize resources.
It would be better without it, but we need it.
