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 1F73DA04B1; Sun, 22 Nov 2020 17:55:32 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2EA1672D8; Sun, 22 Nov 2020 17:55:28 +0100 (CET) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by dpdk.org (Postfix) with ESMTP id 964386CC6 for ; Sun, 22 Nov 2020 17:55:26 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 5B8C359D; Sun, 22 Nov 2020 11:55:24 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 22 Nov 2020 11:55:24 -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= BjBOlLfFJLvYkGdQ8rddB0uera+n6VOzxrV2nc35054=; b=ZP2Di4GTAjO1RlBl WkiYkMibLj1URF93yKfoPi97TFQlqwnZS4m11oOijn/pUuOHSB8WqsS4BhePWP5A Ud2toWgAciWK08f2eZmnx9aJl3JLMZGQMc4752hks26q2B+6W7BPx6VeAjSMZ7NI fmfrzIsOUOAmE203eOl9UqqNoD76rNx0+tqrzlnxzaBfG0VML6ZS/sYFY2u4dHJ5 MLE82Cb+Uww/bcjs8jzxIXXXZEzSQVXhxaeQMqnHDvTB9+VM5Uk/UeH9I93hG+Sz 9DNUvtZ435IZilcxRbE0F5ZWOyyVCwYtkJErDx+QaHQfusZVuUhbYbyylMD8pFKg ckZ03g== 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=BjBOlLfFJLvYkGdQ8rddB0uera+n6VOzxrV2nc350 54=; b=a7Sbmvmor9ii+N2KEq8AbvsAGtB4CL5mZd831AJ6kOAvCOu1hGHPmEmm+ fzSSF6u5mVZHwhJmatwYs8+e45ntCDBC06mGNo4DMEzj862CHrGDGEEcEvDOXez8 gTTFtoLa43zFbX/e5QuFzP7m62BmpqMmHY8YqX8PZIU0H3rKgGTxQ7W5c2sCguJv tapwPELqNJN8kfoRpzdB36AR+ic4cbt8IWVTccRU5Ml2KzN7ITI7MaEPK4t05Gmq zxDqcbyP7IOF2s+HYTdORcU9523Fu4Irpq6UrB3MRVAhsvP7/3pZ/ms0PU0Jgqxt vMchJLUwNDYaMXH8b5Yc1p6YWwGPg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeggedgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght 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 F10C43064AA7; Sun, 22 Nov 2020 11:55:21 -0500 (EST) From: Thomas Monjalon To: andrew.rybchenko@oktetlabs.ru Cc: getelson@nvidia.com, dev@dpdk.org, matan@nvidia.com, Ori Kam , ferruh.yigit@intel.com Date: Sun, 22 Nov 2020 17:55:20 +0100 Message-ID: <2076472.bjLukMjepe@thomas> In-Reply-To: <20201118161520.4378-1-getelson@nvidia.com> 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" Andrew, any comment on this v2? (disclosure: I did not read it) 18/11/2020 17:15, Gregory Etelson: > 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 | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst > index ea203e0ca4..4cff9332fa 100644 > --- a/doc/guides/prog_guide/rte_flow.rst > +++ b/doc/guides/prog_guide/rte_flow.rst > @@ -3229,10 +3229,12 @@ Caveats > temporarily replacing the burst function pointers), an appropriate error > code must be returned (``EBUSY``). > > -- 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. > > For devices exposing multiple ports sharing global settings affected by flow > rules: >