From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6B3CFA0C43; Wed, 20 Oct 2021 12:39:45 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E8A3740687; Wed, 20 Oct 2021 12:39:44 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 1646E40142 for ; Wed, 20 Oct 2021 12:39:44 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 9B22B7F53A; Wed, 20 Oct 2021 13:39:43 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 9B22B7F53A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1634726383; bh=qO3uSzqi8Zs3r/v1yUQvYcqfW3QIPkWXiEKvwx4lq8I=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=InMdlSe0NRQLNtk8fxtWCM9gq2897YKtadF1lHANp2sAqvZrd2HNbMOmvp5LtNXaR bxvMx4/JxVRVgMG6m+KnFSaAPPMZ1sn0iIrKhmibVBZTeFK8keaM8oy5eSmKDoB8xT JwAC/j7q18Rmtsq83TpJ07bO993lnPZtK2nWlbcs= To: Dmitry Kozlyuk , dev@dpdk.org Cc: Qi Zhang , Ori Kam , Thomas Monjalon , Ferruh Yigit References: <20211015161822.3099818-1-dkozlyuk@nvidia.com> <20211019123722.3414694-1-dkozlyuk@nvidia.com> <20211019123722.3414694-2-dkozlyuk@nvidia.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: Date: Wed, 20 Oct 2021 13:39:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211019123722.3414694-2-dkozlyuk@nvidia.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3 1/6] ethdev: add capability to keep flow rules on restart X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/19/21 3:37 PM, Dmitry Kozlyuk wrote: > Previously, it was not specified what happens to the flow rules > when the device is stopped, possibly reconfigured, then started. > If flow rules were kept, it could be convenient for application > developers, because they wouldn't need to save and restore them. > However, due to the number of flows and possible creation rate it is > impractical to save all flow rules in DPDK layer. This means that flow > rules persistence really depends on whether PMD and HW can implement it > efficiently. It can also be limited by the rule item and action types, > and its attributes transfer bit (a combination of an item/action type > and a value of the transfer bit is called a ruel feature). > > Add a device capability bit for PMDs that can keep at least some > of the flow rules across restart. Without this capability behavior > is still unspecified and it is declared that the application must > flush the rules before stopping the device. > Allow the application to test for persitence of rules using persitence -> persistence > a particular feature by attempting to create a flow rule > using that feature when the device is stopped > and checking for the specific error. > This is logical because if the PMD can to create the flow rule > when the device is not started and use it after the start happens, > it is natural that it can move its internal flow rule object > to the same state when the device is stopped and restore the state > when the device is started. > > Rule persistence across a reconfigurations is not required, > because tracking all the rules and configuration-dependent resources > they use may be infeasible. In case a PMD cannot keep the rules > across reconfiguration, it is allowed just to report an error. > Application must then flush the rules before attempting it. > > Signed-off-by: Dmitry Kozlyuk > --- > doc/guides/prog_guide/rte_flow.rst | 25 +++++++++++++++++++++++++ > lib/ethdev/rte_ethdev.h | 7 +++++++ > lib/ethdev/rte_flow.h | 1 + > 3 files changed, 33 insertions(+) > > diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst > index 2b42d5ec8c..ff67b211e3 100644 > --- a/doc/guides/prog_guide/rte_flow.rst > +++ b/doc/guides/prog_guide/rte_flow.rst > @@ -87,6 +87,31 @@ To avoid resource leaks on the PMD side, handles must be explicitly > destroyed by the application before releasing associated resources such as > queues and ports. > > +If ``RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP`` is not advertised, > +rules cannot be created until the device is started for the first time > +and cannot be kept when the device is stopped. > +However, PMD also does not flush them automatically on stop, > +so the application must call ``rte_flow_flush()`` or ``rte_flow_destroy()`` > +before stopping the device to ensure no rules remain. > + > +If ``RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP`` is advertised, this means > +the PMD can keep at least some rules across the device stop and start. > +However, ``rte_eth_dev_configure()`` may fail if any rules remain, > +so the application must flush them before attempting a reconfiguration. > +Keeping may be unsupported for some types of rule items and actions, > +as well as depending on the value of flow attributes transfer bit. > +A combination of an item or action type and a value of the transfer bit > +is called a rule feature. As I said before a combination is very hard to test and unfriendly to applications. Do we really need to make it that complex? Which PMDs are going to support it? Which cases will really be distinguished and will have different support (keep or not)? > +To test if rules with a particular feature are kept, the application must try > +to create a valid rule using this feature when the device is stopped > +(after it has been configured or started previously). Sorry, it hardly makes sense. Does it suggest an application to: 1. configure 2. start 3. stop 4. check/create flow rules 5. start again as a regular start sequence instead of just configure+start. IMHO, it must be possible to check just after configure without start. Otherwise it looks really bad. > +If it fails with an error of type ``RTE_FLOW_ERROR_TYPE_STATE``, > +rules using this feature are flushed when the device is stopped. Which entity does flush it? > +If it suceeds, such rules will be kept when the device is stopped, suceeds -> succeeds kept and functional? I.e. transfer rules still route traffic to other ports which could be up and running. > +provided they do not use other features that are not supported. > +Rules that are created when the device is stopped, including the rules > +created for the test, will be kept after the device is started. > + > The following sections cover: > > - **Attributes** (represented by ``struct rte_flow_attr``): properties of a