doc: announce change in ethdev flow action port ID

By its very name, action PORT_ID means that packets hit an ethdev with the
given DPDK port ID. At least the current comments don't state the opposite.

However some drivers implement it in a different way and direct traffic to
the opposite end of the "wire" plugged to the given ethdev. For example in
the case of a VF representor traffic is redirected to the corresponding VF
itself rather than to the representor ethdev and OvS uses PORT_ID action
this way.

The documentation must be clarified and, likely, rte_flow_action_port_id
structure should be extended to support both meanings.

Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1f78940..4799b64 100644 (file)
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -128,6 +128,12 @@ 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: 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