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 42703A04E6; Wed, 18 Nov 2020 10:04:09 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0FAAF5AAE; Wed, 18 Nov 2020 10:04:08 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by dpdk.org (Postfix) with ESMTP id E962F5947 for ; Wed, 18 Nov 2020 10:04:05 +0100 (CET) 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 5D7347F551; Wed, 18 Nov 2020 12:04:04 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 5D7347F551 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1605690244; bh=PLf1YkLa5H3FkrkTiAgOgLWJ3eNcrTJnLHQtgusd+Rg=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=ZAR/lP4QECnXHP2l/23w9F1H8uU9301hLV4A2uBFBxLnQqq3lvW63KKeslw4gB+t+ lUrDwNUusPXm5VwrkOeMNsF8ecZCAfailAmkUK1EjW/sTiFyrOYbZY6miH+BqIdKuM pEehcwXI5CCjLymAJ5hlwSbimrYK65/DIwCXgyG4= To: Gregory Etelson Cc: "dev@dpdk.org" , "john.mcnamara@intel.com" , "marko.kovacevic@intel.com" , Matan Azrad , Ori Kam , NBU-Contact-Thomas Monjalon References: <20200916111854.1949-1-getelson@nvidia.com> <20201117191826.19730-1-getelson@nvidia.com> <7065a72b-7224-e047-0aed-8be65ae8340d@oktetlabs.ru> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <017d57a9-70f3-eeef-e43f-9c981e6535aa@oktetlabs.ru> Date: Wed, 18 Nov 2020 12:04:04 +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: Content-Type: text/plain; charset=utf-8 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/18/20 11:59 AM, Gregory Etelson wrote: > Hello Andrew, > >> 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) > > PMD should remove all flows related to hardware resource that was invalidated. Stop? Close? I agree and documentation should say so in a bit clear way.