15/09/2022 09:47, Ivan Malov:
> As I said, match criteria belong in flow pattern. I recognise the
> importance of the problem that you're looking to solve. It's very
> good that you care to address it, but what this patch tries to do
> is to add more match criteria in the form of new attributes with
> rather questionable names... There's a room for improvement.
>
> When I say that new features should not confuse readers, I mean
> a very basic thing: readers know that match criteria all sit
> in the pattern. And they refer to the pattern item enum in
> the code and in documentation to learn about criteria,
> while "struct rte_flow_attr" is an unusual place from
> which to learn about match criteria.
>
> > We should get a conclusion and reflect in the commit changes&logs, and it's
> > easy for others to absorb.
>
> Yes, but before we get to that, perhaps it pays to hear
> more feedback from other reviewers. Thomas? Ori? Andrew?
Sorry I did not read all.
I think the main question is about the use of attributes.
I refer to this commit of Ivan last year which was agreed:
ethdev: deprecate direction attributes in transfer flows
Attributes "ingress" and "egress" can only apply unambiguosly
to non-"transfer" flows. In "transfer" flows, the standpoint
is effectively shifted to the embedded switch. There can be
many different endpoints connected to the switch, so the
use of "ingress" / "egress" does not shed light on which
endpoints precisely can be considered as traffic sources.
Add relevant deprecation notices and suggest the use of precise
traffic source items (PORT_REPRESENTOR and REPRESENTED_PORT).
Signed-off-by: Ivan Malov <ivan.ma...@oktetlabs.ru>
Acked-by: Ori Kam <or...@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>
Acked-by: Viacheslav Ovsiienko <viachesl...@nvidia.com>
So +1 for using only pattern items as matching criteria.
