From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) by dpdk.org (Postfix) with ESMTP id 98B937CFD for ; Wed, 14 Jun 2017 15:35:40 +0200 (CEST) Received: by mail-lf0-f42.google.com with SMTP id o83so750370lff.3 for ; Wed, 14 Jun 2017 06:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=nyZLWLNlP8XplNm10Y8bhKveNETDOnx/YLdTFIglo0w=; b=uIcRk5BTS1lSsc4424rICM/dVJB2u73H7lvLiKpmQOQWPYJEaFIHU1ABH9wh7w6o9z 1pIA5L3S+mOcgZDDAOe7V6Ig5lNqdNkd867x/xhlRxdcTjDZZqrBJvyqqv+/CSzUgHq+ Wpkso+rKf2vQYc2dlLdJnDl0NcDV1MS8u2dsfR5EYdGC04kfmmfoMGd52jamt29aWmNK J6rW7hWGR88uO3yvLLCNQluCgRyUXccFQdl39x/A6QwtO9hCaXgsh9lINCynnxrPADJ6 Cd6tYEE8WGCDBC31ppnA7otHIOde+Q3GIWV2/NAe6yrRMG6mX+POSrHjUxoIWciwnwST 59pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=nyZLWLNlP8XplNm10Y8bhKveNETDOnx/YLdTFIglo0w=; b=EWqVk+IGq5c9ByYKQc5S8oS0kvSnVlMaQrdyaZk4enV5OEQFvxdOtpTofgbmBRUu4w P/gm3d2p0zvofcOt9y5Olh9stG2EjBEJX0F7vhEa08knyjfHstEKNbhQWbhclqv8yOJB zIZafiFSRKiZuXw3YWqJEN5Usxtpfu2Vk+Bqma+tKTpaAdYYK6uQX2mx3wyO8twBg/oI obb8axgiWcFuOdiglJxv7daH4ds73seoHBgySVKG5vKjIP7qppT7fDTRHCioDn7tUE0Y cgeOHEW6UJWKoLAJSVg7iUguouDy4xPKXCciT4YydlPx5zAWI0ou4XpE5OIM3ZteokXM +Q0w== X-Gm-Message-State: AKS2vOwSvZPWv8ByDEvlYefReernmCkU8kbkPOahbkkd0+9BfiSTPWa/ 8+R0smd83SgV4sufBFU= X-Received: by 10.80.185.3 with SMTP id m3mr79735ede.41.1497447339992; Wed, 14 Jun 2017 06:35:39 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id j2sm16974edh.60.2017.06.14.06.35.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Jun 2017 06:35:39 -0700 (PDT) Date: Wed, 14 Jun 2017 15:35:29 +0200 From: Adrien Mazarguil To: Andrew Rybchenko Cc: dev@dpdk.org Message-ID: <20170614133529.GO1758@6wind.com> References: <94c640cfbddb6afbe6f068efccbc40dc3c0f0a6b.1495637730.git.adrien.mazarguil@6wind.com> <6ed2734fe0baa20cf993434d81375deb1f647179.1497444240.git.adrien.mazarguil@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v3] ethdev: add isolated mode to flow API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 13:35:40 -0000 On Wed, Jun 14, 2017 at 04:01:46PM +0300, Andrew Rybchenko wrote: > 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 > >Acked-by: Nelio Laranjeiro > > > >--- > > > >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(-) > > > > >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? They can technically return nothing/anything as long as they have no effect on received traffic, as described. Modifying existing wrappers that currently return void instead of an error is outside the scope of this patch and requires ABI breakage. This can be done later when the need arises. For mlx4/mlx5, we plan to expose a different set of rte_eth_dev_ops depending on whether isolated mode is toggled. When enabled, the allmulti/promisc/MAC/VLAN/etc callbacks would be NULL for instance, and the associated ethdev wrappers would automatically return an error where applicable. -- Adrien Mazarguil 6WIND