From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1835BA04B1; Tue, 24 Nov 2020 12:05:01 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D95C6C910; Tue, 24 Nov 2020 12:04:58 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 2C10DC902 for <dev@dpdk.org>; Tue, 24 Nov 2020 12:04:56 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B31185C00D5; Tue, 24 Nov 2020 06:04:54 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 24 Nov 2020 06:04:54 -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= wbiJsX+tXclEN8jfbgmRyjyC+jn4nHdOlnx9hY8nENc=; b=P1lWeHzIJdRc/j4n cjm9qtSg//q3WMG4fszYWwBzQSZD82i6tXbJSrLHnq0wSC+qvdqIT/ops4tZ8baH gWAyAagsqGi73yDkPG41WN7Jm0P+3dQ2Cc2b8ou70twGhRBnxYKafj91UERGTI3y EP1NXYfw6WFg4X3SmkCd4zN7jXG/cCwGRTWkXFdZ2tgRwpHdQ+Tsp5jyCOTXIrAC xseo+8wxqmKMUEzsDgLDyoXMlLGRDus6sX8yiupNM5thpWMfq+Rvrnu78Nywcjxe FJY03GMcWTCEaoczni06amn6M7Qdsvzi0eoujxPorwj1VMmrNxD/P5pJ5FetdzLp 2nLnNg== 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=wbiJsX+tXclEN8jfbgmRyjyC+jn4nHdOlnx9hY8nE Nc=; b=i4NZj/xb5YXUYPzrMHzKqe8n1qCKS0ON646qEq6g67lImScCXBTh2Htkk nZvGuldvJmJMke90J99vTLueA09Axh/OssKYpwDg4sRDb64jfd/qY+66tBQln0DS ++oA1Xf7PDTilU0ReHshD4tmN51VzbMnFEt6N0+eXZD17GEMOvixFcIfcgRQ7MHy zNLwV/XiZZK1C7mfyUQs3cJGG7qVJEyjx9/AkEY9ikkWkFv9nHpk/2HwjkPzpczN IV+SnJ1np5LIqGCoGhF4cHYxsmET9v8uhnT6ZZxqFR+IMAAGhSd9PXvX5xO4yvJy WAqWPe39eo6Im5Lo4pL++t8eLE+LA== X-ME-Sender: <xms:1ei8X_KugFBCZhiXd6jt0qjVRxPs8jpwS0TKIf9wpAYpu2tB78AN5Q> <xme:1ei8XzIFBk_ZtkmxFkNQy68R-S2FR6YWGoTqxr2y8VDFIimPkexjhRqAifui6ee2M SsHb3R-W7vzQMST9Q> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudegkedgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdvffejueetleefieeludduuefgteejleevfeekjeefieegheet ffdvkeefgedunecuffhomhgrihhnpeguphgukhdrohhrghenucfkphepjeejrddufeegrd dvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: <xmx:1ei8X3t6syvVQQbMduV6xUOW2iBfyrW0mE0hhEs8fpHn58UqCsXECQ> <xmx:1ei8X4YUvbNForZLt7JYFWgtcoRIxcEvKGHHH0bzbNPNKwODJiywuA> <xmx:1ei8X2blvcPdzy_e4ujvrOtDb9i8qN2gNPlDUCfnFt3LhDlhgZLIbQ> <xmx:1ui8X2EqtA1dkPYaftuGvwucoMchxQ8bE-Fdq0BH_mjFfsjdNz80Sw> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 0C3263064AB4; Tue, 24 Nov 2020 06:04:52 -0500 (EST) From: Thomas Monjalon <thomas@monjalon.net> To: andrew.rybchenko@oktetlabs.ru, ferruh.yigit@intel.com Cc: dev@dpdk.org, getelson@nvidia.com, dev@dpdk.org, matan@nvidia.com, Ori Kam <orika@nvidia.com> Date: Tue, 24 Nov 2020 12:04:51 +0100 Message-ID: <3388506.zBEybLLHgT@thomas> In-Reply-To: <2076472.bjLukMjepe@thomas> References: <20200916111854.1949-1-getelson@nvidia.com> <20201118161520.4378-1-getelson@nvidia.com> <2076472.bjLukMjepe@thomas> 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> There is also a testpmd patch pending about this behaviour: https://patches.dpdk.org/patch/75353/ 22/11/2020 17:55, Thomas Monjalon: > 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 <getelson@nvidia.com> > > Acked-by: Ori Kam <orika@nvidia.com> > > --- > > 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: