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 C1984A04B0; Tue, 17 Nov 2020 20:56:30 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4ED6937B1; Tue, 17 Nov 2020 20:56:29 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by dpdk.org (Postfix) with ESMTP id 26244DED for ; Tue, 17 Nov 2020 20:56:27 +0100 (CET) Received: from [192.168.1.192] (unknown [188.242.181.57]) (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 753547F51B; Tue, 17 Nov 2020 22:56:25 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 753547F51B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1605642985; bh=IpzkCahb73pSZXRjFRyMAMaL45Si76nR1ewY2SVelkw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=mrSXKGXYBfMIlK1xcKMSCn8EkmrOAIxHLwt+rOzBQJREUMl2mHqhYpREI7Nloe2ns lIMhgW/tqGvCY1Tu+8Yn+IPxg2XX1qH/aXQMDr+Lbd0okdcopjvepMXXDcsI33Fn5P FHPM2uSMFgHHOHgia2+TIHzI4jGbVO6Rzi4/pEwc= To: Gregory Etelson Cc: dev@dpdk.org, john.mcnamara@intel.com, marko.kovacevic@intel.com, matan@nvidia.com, orika@nvidia.com, thomas@monjalon.net References: <20200916111854.1949-1-getelson@nvidia.com> <20201117191826.19730-1-getelson@nvidia.com> From: Andrew Rybchenko Message-ID: <7065a72b-7224-e047-0aed-8be65ae8340d@oktetlabs.ru> Date: Tue, 17 Nov 2020 22:56:23 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20201117191826.19730-1-getelson@nvidia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] 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" On 11/17/20 10:18 PM, 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 > --- > doc/guides/prog_guide/rte_flow.rst | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst > index 944e8242d6..dfe5a40f8e 100644 > --- a/doc/guides/prog_guide/rte_flow.rst > +++ b/doc/guides/prog_guide/rte_flow.rst > @@ -3055,10 +3055,9 @@ Caveats > temporarily replacing the burst function pointers), an appropriate error > code must be returned (``EBUSY``). > > -- PMDs, not applications, are responsible for maintaining flow rules > +- Applications, not PMDs, 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. > + actions which may affect them. > > For devices exposing multiple ports sharing global settings affected by flow > rules: > Re-reading it, it still looks vague. What happens on: - port stop without removal of flow rule before - port close without removal of flow rules before - port reset (which could be stop/start, e.g. to recover from error condition)