[dpdk-dev] [PATCH v3] ethdev: add isolated mode to flow API
arybchenko at solarflare.com
Wed Jun 14 15:01:46 CEST 2017
On 06/14/2017 03:45 PM, Adrien Mazarguil wrote:
> Isolated mode can be requested by applications on individual ports to avoid
> ingress traffic outside of the flow rules they define.
> Besides making ingress more deterministic, it allows PMDs to safely reuse
> resources otherwise assigned to handle the remaining traffic, such as
> global RSS configuration settings, VLAN filters, MAC address entries,
> legacy filter API rules and so on in order to expand the set of possible
> flow rule types.
> To minimize code complexity, PMDs implementing this mode may provide
> partial (or even no) support for flow rules when not enabled (e.g. no
> priorities, no RSS action). Applications written to use the flow API are
> therefore encouraged to enable it.
> Once effective, leaving isolated mode may not be possible depending on PMD
> Signed-off-by: Adrien Mazarguil <adrien.mazarguil at 6wind.com>
> Acked-by: Nelio Laranjeiro <nelio.laranjeiro at 6wind.com>
> - Rebased on next-net/master. Note this patch depends on
> commit c0688ef1eded ("net/igb: parse flow API n-tuple filter") due to a
> necessary fix in igb's rte_flow_ops definition to avoid a compilation
> - Rebased on master.
> app/test-pmd/cmdline.c | 4 ++
> app/test-pmd/cmdline_flow.c | 49 ++++++++++++++++++++-
> app/test-pmd/config.c | 16 +++++++
> app/test-pmd/testpmd.h | 1 +
> doc/guides/prog_guide/rte_flow.rst | 56 ++++++++++++++++++++++++
> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 48 +++++++++++++++++++-
> drivers/net/e1000/igb_flow.c | 9 ++--
> drivers/net/ixgbe/ixgbe_flow.c | 9 ++--
> lib/librte_ether/rte_ether_version.map | 7 +++
> lib/librte_ether/rte_flow.c | 18 ++++++++
> lib/librte_ether/rte_flow.h | 33 ++++++++++++++
> lib/librte_ether/rte_flow_driver.h | 5 +++
> 12 files changed, 242 insertions(+), 13 deletions(-)
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index b587ba9..699d2b2 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1517,6 +1517,62 @@ Return values:
> - 0 on success, a negative errno value otherwise and ``rte_errno`` is set.
> +Isolated mode
> +The general expectation for ingress traffic is that flow rules process it
> +first; the remaining unmatched or pass-through traffic usually ends up in a
> +queue (with or without RSS, locally or in some sub-device instance)
> +depending on the global configuration settings of a port.
> +While fine from a compatibility standpoint, this approach makes drivers more
> +complex as they have to check for possible side effects outside of this API
> +when creating or destroying flow rules. It results in a more limited set of
> +available rule types due to the way device resources are assigned (e.g. no
> +support for the RSS action even on capable hardware).
> +Given that nonspecific traffic can be handled by flow rules as well,
> +isolated mode is a means for applications to tell a driver that ingress on
> +the underlying port must be injected from the defined flow rules only; that
> +no default traffic is expected outside those rules.
> +This has the following benefits:
> +- Applications get finer-grained control over the kind of traffic they want
> + to receive (no traffic by default).
> +- More importantly they control at what point nonspecific traffic is handled
> + relative to other flow rules, by adjusting priority levels.
> +- Drivers can assign more hardware resources to flow rules and expand the
> + set of supported rule types.
> +Because toggling isolated mode may cause profound changes to the ingress
> +processing path of a driver, it may not be possible to leave it once
> +entered. Likewise, existing flow rules or global configuration settings may
> +prevent a driver from entering isolated mode.
> +Applications relying on this mode are therefore encouraged to toggle it as
> +soon as possible after device initialization, ideally before the first call
> +to ``rte_eth_dev_configure()`` to avoid possible failures due to conflicting
I think it would be useful to highlight how isolated mode coexists with
and all-multicast. What is the expected behaviour of the functions which
promiscuous and all-multicast mode if isolated mode is enabled? These
return void right now, so it is impossible to return error. What should
rte_eth_promiscuous_get() and rte_eth_allmulticast_get() return?
More information about the dev