[dpdk-dev] [PATCH v3 00/12] ethdev: rework transfer flow API
Ferruh Yigit
ferruh.yigit at intel.com
Wed Oct 13 13:51:01 CEST 2021
On 10/10/2021 3:39 PM, Ivan Malov wrote:
> As per RFC [1], action PORT_ID appears to be ambiguous. Its name suggests
> that matching traffic be sent to the ethdev with the specified ID, that
> is, to the application. However, in Open vSwitch, the action is used to
> send traffic to a remote entity represented by the given port, that is,
> in the opposite direction. Its interpretation across PMDs also varies.
>
> RFC [2] attempted to define action PORT_ID semantics in vSwitch sense.
> However, this solution would completely abandon the opposite meaning.
>
> One more effort, RFC [3], was meant to declare that the use of direction
> attributes in "transfer" flows assumed implicit filtering by the port ID
> appearing as the first argument in rte_flow_create(). However, not all
> PMDs require such filtering, so the RFC turned out rather disputable.
>
>
> Since then, all of that has been given more thought:
>
> 1. One should not attempt to fix action PORT_ID. Instead, two new actions
> should be introduced. The first one should send traffic to the given
> ethdev. The second one should send it to the represented entity.
>
> 2. Similar to (1), two new items should be defined. The first one should
> match traffic going down from the given ethdev. The second one should
> match traffic going up from the entity represented by that ethdev.
>
> 3. The application always knows which packets come through which ethdevs.
> So, as per (2), the application can use the new item to match traffic
> arriving from precise entities represented by the relevant ethdev IDs.
>
> 4. New items suggested in (2) do not require the use of direction
> attributes. These items define precise directions on their own.
>
> 5. As a consequence of (3) and (4), the problem of implicit filtering
> by rte_flow_create() port ID argument and direction attributes is
> no longer a blocker. The new items allow to dispose of it.
>
>
> The new items appear to be symmetrical to each other. So do the new
> actions. This requires that their names reflect the symmetry. Also,
> the names should respect the existing concept of port representors.
> By the looks of it, terms "PORT_REPRESENTOR" and "REPRESENTED_PORT"
> satisfy these requirements. However, currently, ethdevs associated
> with network ports are not considered as their representors. Such
> understanding is mentioned in the documentation, but it's not
> expressed in the code (see enum rte_eth_representor_type).
>
>
> The short of it, this patch series follows points (1-5) to rework
> support for "transfer" flows accordingly. On the way, a string of
> ambiguous pattern items (PF, VF, PHY_PORT) is deprecated.
>
> The patch series also updates PMDs which support item and action PORT_ID
> to add support for replacements (1-2). However, there're some exceptions:
>
> - Support for traffic source items in the case of net/mlx5 is really
> complicated. This series does not rework it. The PMD maintainer
> can do the job much better and test the new code accordingly;
>
> - Support for action REPRESENTED_PORT is not added to net/sfc.
> This will be done when support for VF representors has been
> upstreamed, just for the new code to apply cleanly.
>
>
> Changes in v2:
> * New naming and reworked comments
> * New diagrams
>
> Changes in v3:
> * Diagram improvements
> * Spelling fixes
>
> [1] https://patches.dpdk.org/project/dpdk/patch/20210907125157.3843-1-ivan.malov@oktetlabs.ru/
> [2] https://patches.dpdk.org/project/dpdk/patch/20210903074610.313622-1-andrew.rybchenko@oktetlabs.ru/
> [3] https://patches.dpdk.org/project/dpdk/patch/20210901151104.3923889-1-andrew.rybchenko@oktetlabs.ru/
>
> Andrew Rybchenko (6):
> net/bnxt: support meta flow items to match on traffic source
> net/bnxt: support meta flow actions to overrule destinations
> net/enic: support meta flow actions to overrule destinations
> net/mlx5: support represented port flow action
> net/octeontx2: support port representor flow action
> net/sfc: support port representor flow item
>
> Ivan Malov (6):
> ethdev: add port representor item to flow API
> ethdev: add represented port item to flow API
> ethdev: add port representor action to flow API
> ethdev: add represented port action to flow API
> ethdev: deprecate hard-to-use or ambiguous items and actions
> ethdev: deprecate direction attributes in transfer flows
>
The rte flow documentation script is failing [1], should new actions
added to the documentation?
[1]
./devtools/check-doc-vs-code.sh
rte_flow doc out of sync for bnxt
item port_representor
item represented_port
action port_representor
action represented_port
rte_flow doc out of sync for enic
action port_representor
action represented_port
rte_flow doc out of sync for mlx5
action represented_port
rte_flow doc out of sync for octeontx2
action port_representor
rte_flow doc out of sync for sfc
item port_representor
More information about the dev
mailing list