From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
To: Thomas Monjalon <thomas@monjalon.net>,
Ferruh Yigit <ferruh.yigit@intel.com>, Ori Kam <orika@nvidia.com>
Cc: dev@dpdk.org, Eli Britstein <elibr@nvidia.com>,
Ilya Maximets <i.maximets@ovn.org>,
Ajit Khaparde <ajit.khaparde@broadcom.com>,
Ivan Malov <ivan.malov@oktetlabs.ru>,
John Daley <johndale@cisco.com>,
Hyong Youb Kim <hyonkim@cisco.com>,
Jerin Jacob <jerinj@marvell.com>,
Nithin Dabilpuram <ndabilpuram@marvell.com>,
Kiran Kumar K <kirankumark@marvell.com>,
Somnath Kotur <somnath.kotur@broadcom.com>
Subject: [dpdk-dev] [PATCH v1] ethdev: clarify flow action PORT ID semantics
Date: Fri, 3 Sep 2021 10:46:10 +0300 [thread overview]
Message-ID: <20210903074610.313622-1-andrew.rybchenko@oktetlabs.ru> (raw)
In-Reply-To: <20210601111420.5549-1-ivan.malov@oktetlabs.ru>
From: Ivan Malov <ivan.malov@oktetlabs.ru>
Definition of action PORT_ID is ambiguous.
Documentation says "Directs matching traffic to a given DPDK port ID."
It suggests that an application will receive corresponding traffic on
the port using ethdev Rx burst API. Some network PMDs implement PORT_ID
action this way.
However, OvS+DPDK uses PORT_ID action a way which is natural it to
bypass OvS and redirect corresponding traffic to wire if the DPDK port
is a physical function or to a virtual function if the DPDK port is
a VF representor. Anyway corresponding packets will not be received
using ethdev Rx burst API by the OvS+DPDK. Other network PMDs implement
the PORT_ID action following the semantics.
The latter semantics may be explained to match the above definition
taking port representor definition into account which says that port
representor is a ghost of the real port and redirecting a traffic to
it means redirecting the traffic to the corresponding real port.
However, representors are not the only use case, and solution should
be extended anyway to support both options.
Since these interpretations of the PORT_ID action semantics are basically
opposite and both have reasons behind, it is bad to silently break some
applications changing default meaning. So make it backward incompatible
to ensure that all applications are updated to use it in a right way.
Stick to ingress/egress terminology to specify direction since it is
well defined from DPDK application point of view:
- ingress to be received via the specified port;
- egress as if it would-be transmitted via the specified port.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
The patch is a follow up of the long discussion of the RFC [1].
It is just an attempt to summarize some results of the discussion.
Small quote from the discussion:
On June 3, 2021, 11:05 a.m. UTC, Ilya Maximets wrote:
> On June 3, 2021, 10:33 a.m. UTC, Andrew Rybchenko wrote:
> >
> > A. Add "ingress" bit with "egress" as unset meaning.
> > Yes, that's what is current behaviour assumed and
> > used by OvS and implemented in some PMDs.
> > My problem with it that it is, IMHO, inconsistent
> > default value (as explained above).
> >
> > B. Add "egress" bit with "ingress" as unset meaning.
> > Basically it is what is suggested in the RFC, but
> > the problem of the suggestion is the silent breakage
> > of existing users (let's put it a side if it is
> > correct usage or misuse). It is still the fact.
> >
> > C. Encode above in ethdev port ID MSB.
> > The problem of the solution is that encoding
> > makes sense for representors, but the problem
> > exists for non-representor ports as well.
> > I have no good ideas on terminology in the case
> > if we try to solve it for non-representors.
> >
> > D. Break API and ABI and add enum with unset(default)/
> > ingress/egress members to enforce application to
> > specify direction.
> >
> > It is unclear what we'll do in the case of A, B and D
> > if we encode representor in port ID MSB in any case.
>
> My opinion:
>
> - Option D is the best choice for rte_flow. No defaults, users forced
> to explicitly choose the direction in HW-independent way.
>
> - I agree that option C somewhat conflicts with the 'ingress/egress'
> flag idea and it is more hardware-specific. Therefore if option C
> is going to be implemented it should be implemented in concept of
> option A, i.e. 'egress' is default option if port ID MSB is not set.
If the solution is accepted, testpmd must be updated to require action
direction specification and drivers which implement the action must be
updated to handle direction properly and reject unspecified value with
appropriate error message.
If the patch does not address all concerns and there is still
significant disagreement on the topic, it would be good to schedule
call to discuss it.
[1] https://patches.dpdk.org/project/dpdk/patch/20210601111420.5549-1-ivan.malov@oktetlabs.ru/
doc/guides/prog_guide/rte_flow.rst | 7 ++++++-
doc/guides/rel_notes/deprecation.rst | 6 ------
doc/guides/rel_notes/release_21_11.rst | 4 ++++
lib/ethdev/rte_flow.h | 25 ++++++++++++++++++++++++-
4 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 2b42d5ec8c..89404b38af 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1919,7 +1919,10 @@ See `Item: PHY_PORT`_.
Action: ``PORT_ID``
^^^^^^^^^^^^^^^^^^^
-Directs matching traffic to a given DPDK port ID.
+
+Directs matching traffic to the specified DPDK port (ingress) or to
+the would-be destination as if the application itself sent this traffic
+from the said DPDK port (egress).
See `Item: PORT_ID`_.
@@ -1934,6 +1937,8 @@ See `Item: PORT_ID`_.
+--------------+---------------------------------------+
| ``id`` | DPDK port ID |
+--------------+---------------------------------------+
+ | ``dir`` | egress or ingress |
+ +--------------+---------------------------------------+
Action: ``METER``
^^^^^^^^^^^^^^^^^
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 76a4abfd6b..4ec6927c86 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -128,12 +128,6 @@ Deprecation Notices
is deprecated and will be removed in DPDK 21.11. Shared counters should
be managed using shared actions API (``rte_flow_shared_action_create`` etc).
-* ethdev: Definition of the flow API action ``RTE_FLOW_ACTION_TYPE_PORT_ID``
- is ambiguous and needs clarification.
- Structure ``rte_flow_action_port_id`` will be extended to specify
- 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
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index d707a554ef..b7aa175a32 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -84,6 +84,10 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* ethdev: ``struct rte_flow_action_port_id`` is extended with the direction
+ field with unspecified default, so all ``PORT_ID`` flow API action users
+ must be updated to make correct choice.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 70f455d47d..3b83ed7d3a 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -2632,10 +2632,32 @@ struct rte_flow_action_phy_port {
uint32_t index; /**< Physical port index. */
};
+/** Traffic direction from application point of view. */
+enum rte_flow_direction {
+ /**
+ * Invalid value which should not be used and must be
+ * rejected by drivers.
+ */
+ RTE_FLOW_DIRECTION_UNSPECIFIED = 0,
+ /** As if the traffic was sent by the application. */
+ RTE_FLOW_EGRESS,
+ /** To be received by the application. */
+ RTE_FLOW_INGRESS,
+};
+
/**
* RTE_FLOW_ACTION_TYPE_PORT_ID
*
- * Directs matching traffic to a given DPDK port ID.
+ * Directs matching traffic to an ethdev with the given DPDK port ID or
+ * to the upstream port (the peer side of the wire) corresponding to it.
+ *
+ * It's assumed that it's the PMD (typically, its instance at the admin
+ * PF) which controls the binding between a (representor) ethdev and an
+ * upstream port. Typical bindings: VF rep. <=> VF, PF <=> network port.
+ * If the PMD instance is unaware of the binding between the ethdev and
+ * its upstream port (or can't control it), it should reject the action
+ * with the egress direction specified and log an appropriate error
+ * message.
*
* @see RTE_FLOW_ITEM_TYPE_PORT_ID
*/
@@ -2643,6 +2665,7 @@ struct rte_flow_action_port_id {
uint32_t original:1; /**< Use original DPDK port ID if possible. */
uint32_t reserved:31; /**< Reserved, must be zero. */
uint32_t id; /**< DPDK port ID. */
+ enum rte_flow_direction dir; /**< Direction to route traffic to. */
};
/**
--
2.30.2
prev parent reply other threads:[~2021-09-03 7:46 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-01 11:14 [dpdk-dev] [RFC PATCH] " Ivan Malov
2021-06-01 12:10 ` Ilya Maximets
2021-06-01 13:24 ` Eli Britstein
2021-06-01 14:35 ` Andrew Rybchenko
2021-06-01 14:44 ` Eli Britstein
2021-06-01 14:50 ` Ivan Malov
2021-06-01 14:53 ` Andrew Rybchenko
2021-06-02 9:57 ` Eli Britstein
2021-06-02 10:50 ` Andrew Rybchenko
2021-06-02 11:21 ` Eli Britstein
2021-06-02 11:57 ` Andrew Rybchenko
2021-06-02 12:36 ` Ivan Malov
2021-06-03 9:18 ` Ori Kam
2021-06-03 9:55 ` Andrew Rybchenko
2021-06-07 8:28 ` Thomas Monjalon
2021-06-07 9:42 ` Andrew Rybchenko
2021-06-07 12:08 ` Ori Kam
2021-06-07 13:21 ` Ilya Maximets
2021-06-07 16:07 ` Thomas Monjalon
2021-06-08 16:13 ` Thomas Monjalon
2021-06-08 16:32 ` Andrew Rybchenko
2021-06-08 18:49 ` Thomas Monjalon
2021-06-09 14:31 ` Andrew Rybchenko
2021-06-01 14:49 ` Ivan Malov
2021-06-01 14:28 ` Ivan Malov
2021-06-02 12:46 ` Ilya Maximets
2021-06-02 16:26 ` Andrew Rybchenko
2021-06-02 17:35 ` Ilya Maximets
2021-06-02 19:35 ` Ivan Malov
2021-06-03 9:29 ` Ilya Maximets
2021-06-03 10:33 ` Andrew Rybchenko
2021-06-03 11:05 ` Ilya Maximets
2021-06-03 11:29 ` Ivan Malov
2021-06-07 19:27 ` Ilya Maximets
2021-06-07 20:39 ` Ivan Malov
2021-06-25 13:04 ` Ferruh Yigit
2021-06-02 12:16 ` Thomas Monjalon
2021-06-02 12:53 ` Ilya Maximets
2021-06-02 13:10 ` Andrew Rybchenko
2021-09-03 7:46 ` Andrew Rybchenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210903074610.313622-1-andrew.rybchenko@oktetlabs.ru \
--to=andrew.rybchenko@oktetlabs.ru \
--cc=ajit.khaparde@broadcom.com \
--cc=dev@dpdk.org \
--cc=elibr@nvidia.com \
--cc=ferruh.yigit@intel.com \
--cc=hyonkim@cisco.com \
--cc=i.maximets@ovn.org \
--cc=ivan.malov@oktetlabs.ru \
--cc=jerinj@marvell.com \
--cc=johndale@cisco.com \
--cc=kirankumark@marvell.com \
--cc=ndabilpuram@marvell.com \
--cc=orika@nvidia.com \
--cc=somnath.kotur@broadcom.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).