From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 606EC7CC9 for ; Wed, 14 Jun 2017 15:02:05 +0200 (CEST) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id DBD79600C0; Wed, 14 Jun 2017 13:02:04 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx4-us3.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 9B2706004C; Wed, 14 Jun 2017 13:02:02 +0000 (UTC) Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx4-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 53318801AA; Wed, 14 Jun 2017 13:02:01 +0000 (UTC) Received: from [192.168.38.17] (84.52.114.114) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 14 Jun 2017 14:01:57 +0100 To: Adrien Mazarguil , References: <94c640cfbddb6afbe6f068efccbc40dc3c0f0a6b.1495637730.git.adrien.mazarguil@6wind.com> <6ed2734fe0baa20cf993434d81375deb1f647179.1497444240.git.adrien.mazarguil@6wind.com> From: Andrew Rybchenko Message-ID: Date: Wed, 14 Jun 2017 16:01:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6ed2734fe0baa20cf993434d81375deb1f647179.1497444240.git.adrien.mazarguil@6wind.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [84.52.114.114] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23130.003 X-TM-AS-Result: No--17.744100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1497445323-M8h+Ds7Mr8I7 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:02:05 -0000 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?