From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 20BFEA0545; Thu, 26 Nov 2020 00:34:11 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B871CC960; Thu, 26 Nov 2020 00:34:08 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 1C04FC95E for ; Thu, 26 Nov 2020 00:34:08 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 890155C00F0; Wed, 25 Nov 2020 18:34:04 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 25 Nov 2020 18:34:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= fqGcllUSjqDpJ1fCyRh41HgWyxLgq7gleuBOGGE3Kbw=; b=EzLSvJUR8nETm1sc 5rQ+oRfBMUN3DPbxEzquFytw5bhgPFEhidCyprWoSR50DkrIBsCgVr1bNxEPhbf8 whum7HtlTXUJDr7XT3sbOsWZ6rD14hG3jEYetyAk8ziYa/vcPzCjeEcQeDrBelDQ Pa7iSATC8/dJdFFRcdC9eLAmhaHhBzXEoN04UNIfJMHbu5gRRPqLImc0ugfExdCZ 1aIhsATiHZB6vFO6fcoFR8ZCoSCUy1Z4DQZsjjsxVy0njT4zBF/TkdBtI9xZ9Bv8 NI2+NvyYNahyxEOvMfLk/8Gnupobjo9Mhol8/6wah2c5GsE8JiSucbciqcxFvMiX uk12gA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=fqGcllUSjqDpJ1fCyRh41HgWyxLgq7gleuBOGGE3K bw=; b=QH48STGG8qhlybly7nBwOFyXojNkJcn7QkJLIK/pV6RGQ4xUGn5D7gOTR h/wRmtAp3bObIG0R+bhblElKlXhLFA+7nAGa28O67sgWmxStBOySBZl+MgNGumsN Hdl1P8dbjmulJVdDWMsIU0P4pGzHsXDwlsQ2etAxGXyo+mAQaVT98vWGDNIb4UaO qIg/wn07eSABwpzDP0FjWy3oiILVal1oLxKgsjP83IVQI6AS4upNmNsxbngyJsAE c3F7kEurU+2Rpc5vLySULD/WrRQ4kQhZp9RQ1YmPFta9cxJGvWvom1gRZKwD9fLK 8CZJvkI1OZkgSXQCrozNm+xpN+iiA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudehuddguddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdvffejueetleefieeludduuefgteejleevfeekjeefieegheet ffdvkeefgedunecuffhomhgrihhnpeguphgukhdrohhrghenucfkphepjeejrddufeegrd dvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id BB7723064AB3; Wed, 25 Nov 2020 18:34:02 -0500 (EST) From: Thomas Monjalon To: Gregory Etelson Cc: dev@dpdk.org, Matan Azrad , Andrew Rybchenko , Ori Kam , Ajit Khaparde , ferruh.yigit@intel.com, kalesh-anakkur.purayil@broadcom.com, asafp@nvidia.com Date: Thu, 26 Nov 2020 00:33:58 +0100 Message-ID: <3938099.baJt5BIKZU@thomas> In-Reply-To: References: <20200916111854.1949-1-getelson@nvidia.com> <20201118161520.4378-1-getelson@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] doc: flow rule removal on port stop 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 24/11/2020 15:41, Ajit Khaparde: > On Wed, Nov 18, 2020 at 8:15 AM Gregory Etelson wrote: > > > > There is a discrepancy between RTE ETHDEV API and flow rules guide > > regarding flow rules maintenance after port stop. RTE ETHDEV API in > > librte_ethdev.h declares that flow rules will not be stored in PMD > > after port stop: > > >>>>> Quite start > > Please note that some configuration is not stored between calls to > > rte_eth_dev_stop()/rte_eth_dev_start(). The following configuration > > will be retained: > > > > - MTU > > - flow control settings > > - receive mode configuration (promiscuous mode, all-multicast mode, > > hardware checksum mode, RSS/VMDQ settings etc.) > > - VLAN filtering configuration > > - default MAC address > > - MAC addresses supplied to MAC address array > > - flow director filtering mode (but not filtering rules) > > - NIC queue statistics mappings > > <<<< Quote end > > > > PMD cannot always correctly restore flow rules after port stop / port > > start because application may alter port configuration after port stop > > without PMD knowledge about undergoing changes. Consider the > > following scenario: > > application configures 2 queues 0 and 1 and creates a flow rule with > > 'queue index 1' action. After that application stops the port and > > removes queue 1. > > Although PMD can implement flow rule shadow copy to be used for > > restore after port start, attempt to restore flow rule from shadow > > will fail in example above and PMD could not notify application about > > that failure. As the result, flow rules map in HW will differ from > > what application expects. In addition, flow rules shadow copy used > > for port start restore consumes considerable amount of system memory, > > especially in systems with millions of flow rules. > > > > Signed-off-by: Gregory Etelson > > Acked-by: Ori Kam > Acked-by: Ajit Khaparde > > > --- > > -- PMDs, not applications, are responsible for maintaining flow rules > > - configuration when stopping and restarting a port or performing other > > - actions which may affect them. They can only be destroyed explicitly by > > - applications. > > +- Applications, not PMDs, are responsible for maintaining flow rules > > + configuration when closing, stopping or restarting a port or performing other > > + actions which may affect them. > > + Applications must assume that after port close, stop or restart all flows > > + related to that port are not valid, hardware rules are destroyed and relevant > > + PMD resources are released. In short summary, this rte_flow doc change has 3 reasons: - consistency with ethdev API doc - avoid unsolvable automatic flow update after re-configuration - reduce memory consumption for flow rules Andrew was asking, in previous version, how to manage reset for error recovery. As it has been discussed in other threads, an error recovery should be notified to the application. We already have RTE_ETH_EVENT_INTR_RESET for VF in case of PF reset, and a more general recovery notification mechanism is being discussed: https://patches.dpdk.org/patch/80094/ Then it will be possible to notify the application that the flow rules must be restored (among other recovery measures). For the case of port stop/close, doc update applied, thanks.