[dpdk-dev] [PATCH v3] ethdev: add isolated mode to flow API

Andrew Rybchenko 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
> implementation.
>
> Signed-off-by: Adrien Mazarguil <adrien.mazarguil at 6wind.com>
> Acked-by: Nelio Laranjeiro <nelio.laranjeiro at 6wind.com>
>
> ---
>
> v3:
> - 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
>    issue.
>
> v2:
> - 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(-)

<snip>

> 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
> +settings.
> +

I think it would be useful to highlight how isolated mode coexists with 
promiscuous
and all-multicast. What is the expected behaviour of the functions which 
toggle
promiscuous and all-multicast mode if isolated mode is enabled? These 
functions
return void right now, so it is impossible to return error. What should
rte_eth_promiscuous_get() and  rte_eth_allmulticast_get() return?

<snip>


More information about the dev mailing list