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 E4DBD7D12 for ; Wed, 14 Jun 2017 16:04:36 +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 405E56009F; Wed, 14 Jun 2017 14:04:36 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx6-us1.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 40A3C60053; Wed, 14 Jun 2017 14:04:35 +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 mx6-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 4D0594C00AE; Wed, 14 Jun 2017 14:04:34 +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 15:04:28 +0100 To: Adrien Mazarguil References: <94c640cfbddb6afbe6f068efccbc40dc3c0f0a6b.1495637730.git.adrien.mazarguil@6wind.com> <6ed2734fe0baa20cf993434d81375deb1f647179.1497444240.git.adrien.mazarguil@6wind.com> <20170614133529.GO1758@6wind.com> CC: From: Andrew Rybchenko Message-ID: Date: Wed, 14 Jun 2017 17:04:16 +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: <20170614133529.GO1758@6wind.com> 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--27.470100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1497449075-hEm00uP64l3x Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 14:04:37 -0000 On 06/14/2017 04:35 PM, Adrien Mazarguil wrote: > 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. I was just asking to highlight it in the documentation. Yes, idea of the isolated mode is clear and may be it is enough. > 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. It is perfectly clear. > 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. Thanks for the idea. We'll consider it as well. Andrew.