Hi Andrew, PSB
Thanks, Ori > -----Original Message----- > From: dev <dev-boun...@dpdk.org> On Behalf Of Andrew Rybchenko > Sent: Wednesday, September 1, 2021 6:11 PM > > As per existing documentation, attribute "transfer", quote, "complements > the behavior of some pattern items such as > RTE_FLOW_ITEM_TYPE_PHY_PORT and is meaningless without them". That > effectively confronts the idea of implicit filtering imposed by port_id > argument passed by flow create API. > > This bit of documentation is vague, and having no implicit filtering is > unfriendly to applications which insert flow rules on specific ports based on > the source port IDs of the (not offloaded) incoming packets. > > In order to address the problem, document the existence of the implicit > filtering. Use the term "weak" for this filtering as it implies the > possibility to > override it by including explicit traffic source criteria in the flow pattern > (PORT_ID, PHY_PORT and the likes). > > Signed-off-by: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru> > --- > The topic was briefly discussed in mail thread [1]. > > I'm not sure if the patch should have "Fixes:" tag. If it is really behaviour > intended from the very beginning, it should be backported and > corresponding fixes in drivers should be backported as well. > > [1] https://patches.dpdk.org/project/dpdk/patch/20210601111420.5549-1- > ivan.ma...@oktetlabs.ru/ > > doc/guides/prog_guide/rte_flow.rst | 17 ++++++++++++++--- > doc/guides/rel_notes/deprecation.rst | 5 ----- > 2 files changed, 14 insertions(+), 8 deletions(-) > > diff --git a/doc/guides/prog_guide/rte_flow.rst > b/doc/guides/prog_guide/rte_flow.rst > index 2b42d5ec8c..af54939418 100644 > --- a/doc/guides/prog_guide/rte_flow.rst > +++ b/doc/guides/prog_guide/rte_flow.rst > @@ -171,13 +171,24 @@ When supported, this effectively enables an > application to reroute traffic not necessarily intended for it (e.g. coming > from > or addressed to different physical ports, VFs or applications) at the device > level. > > -It complements the behavior of some pattern items such as `Item: > PHY_PORT`_ -and is meaningless without them. > - > When transferring flow rules, **ingress** and **egress** attributes > (`Attribute: Traffic direction`_) keep their original meaning, as if > processing > traffic emitted or received by the application. I know this is original code but what do we mean application? You assume that the application is the switch? Or the application is some DPDK application running on the PF? > > +DPDK port used to create transfer rule is important since it implicitly > +adds filtering by it (similar to `Item: PORT_ID` with ``spec.id`` equal > +to the port ID and exact match mask) if no other items which specify > +source are present in the rule pattern (e.g. `Item: PHY_PORT`, `Item: > +VF` or explicit `Item: PORT_ID`). It means that by default ingress > +rules apply to traffic which comes from associated upstream switch > +port, i.e. physical network port for PF DPDK port, VF for VF > +representor. Egress rules transfer traffic transmitted via > +corresponding DPDK port, i.e. PF DPDK port or VF representor itself. > + To make sure I understand the direction should be defined as follows: Traffic from ---> to Wire --> VF ==> ingress direction. VF --> Wire ==> ingress direction. VF1 --> VF2 ==> ingress direction. VF 1--> VF2 representor ==> ingress. VF representor --> wire ==> egress. VF representor --> VF ==> egress > +It is still possible to apply transfer rule on a traffic originating > +from any switch port using wildcard mask in corresponding pattern item > +if underlying PMD supports it. > + > Pattern item > ~~~~~~~~~~~~ > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 76a4abfd6b..f1d290a911 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -134,11 +134,6 @@ Deprecation Notices > traffic direction to the represented entity or ethdev port itself > in DPDK 21.11. > > -* ethdev: Flow API documentation is unclear if ethdev port used to create > - a flow rule adds any implicit match criteria in the case of transfer rules. > - The semantics will be clarified in DPDK 21.11 and it will require fixes in > - drivers and applications which interpret it in a different way. > - > * ethdev: The flow API matching pattern structures, ``struct > rte_flow_item_*``, > should start with relevant protocol header. > Some matching pattern structures implements this by duplicating protocol > header > -- > 2.30.2
