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 1FD3EA04C9; Sun, 13 Sep 2020 16:00:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 700AA1DB9; Sun, 13 Sep 2020 16:00:40 +0200 (CEST) Received: from wnew4-smtp.messagingengine.com (wnew4-smtp.messagingengine.com [64.147.123.18]) by dpdk.org (Postfix) with ESMTP id EEFFDE07 for ; Sun, 13 Sep 2020 16:00:37 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.west.internal (Postfix) with ESMTP id 13A93745; Sun, 13 Sep 2020 10:00:34 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sun, 13 Sep 2020 10:00:34 -0400 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= EOnJTgbkIgvbDUaf6W6kxMzQwKQkKbfS3wfC+Dziz/E=; b=VEE1O1EnkP4YCRfx fX0r3NWl8Xw9+cD3Ln7UPhLYCIBmXapplVMe+Fxu8jR2Tq7g8desB0AuP9JaOa5d Gbri24nTIpAXMNG5DfURxplcLpwkAcqnZbV7efgbbJsq2PQiETOGGD/Gwa8rraLS CHupjHk80UZGeGIBWnZXDrMqovUrWfph3nvyYtQZGjhLo5SoRU01K8isxaexOKqQ IFqc4MWMWQl5eRbou8QTyZ1nd44XNUOlbMv/JAnhu6wj3+XlOqSh/D+qpiLbrMrJ NFNXY+wVV7fsTXyD1fKs1IcZ4gC6t6eiG6VYC1XwV14XMxC5F9W/OzAp3FLXZjLd 6RK3WQ== 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=fm3; bh=EOnJTgbkIgvbDUaf6W6kxMzQwKQkKbfS3wfC+Dziz /E=; b=WwB4VsLPyZjb3WwuwRnV3+Vx44c0FrbFFz2HN2ywOWTZWgWngJZUYDk4w FB+ekgrtolixBrmfBv06G3R9i/TYvUhSYf6IbZRsZ/SeuYwwUsCf1Xk961BiaDo9 rzbEf5EZQt9tXv1z8eBenKaa1HtRmfE5XsijsR2A9lnmLgoWeBS443hFWPludcmT 8T70ylxHHzZG4d6Cm0r7i16qfKc9RWckCSukf1x9LrTWrn2O6II1xgmRrqX/PyBw kP2ruh9o4DrqzgcoX8S2wVmR3EoZclmJ0EpnDClVAWv8icGTx+Eu1d9/gznOjetE bVd4mI8AWvZjVyqKZgDt6XX8Xo4sw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudeifedgjeduucetufdoteggodetrfdotf 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 8AF9A306467E; Sun, 13 Sep 2020 10:00:31 -0400 (EDT) From: Thomas Monjalon To: Gregory Etelson , Ori Kam Cc: Ferruh Yigit , Wenzhuo Lu , Beilei Xing , Bernard Iremonger , "dev@dpdk.org" , Matan Azrad , Raslan Darawsheh , Jeff Guo , Qi Zhang Date: Sun, 13 Sep 2020 16:00:30 +0200 Message-ID: <4471739.bWhk7Xqv4u@thomas> In-Reply-To: References: <20200810161523.6904-1-getelson@mellanox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] app/testpmd: fix flow rules list after 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" 13/09/2020 14:12, Ori Kam: > Hi Ferruh, > Can we proceed with this patch? Below, you said "first thing to do it update the rte_flow doc". So I am expecting a patch on the doc to start this discussion. This testpmd patch is on hold in my understanding. > From: Ori Kam > > From: Ferruh Yigit > > > On 8/20/2020 9:40 AM, Gregory Etelson wrote: > > > > Hello, > > > > > > > > Is this patch scheduled for merge with dpdk.org ? > > > > Please update me. > > > > > > > >> From: Gregory Etelson > > > >> > > > >> According to current RTE API, port flow rules must not be kept after port > > > >> stop. > > > > > > Hi Gregory, Ori, > > > > > > Can you please point where this is documented? > > > > > From: rte_ethdev.h > > "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" > > > > From my understanding this means that flows should not be stored on device > > stop. > > > > > > > >> > > > >> Testpmd did not flush port flow rules after `port stop' command was > > called. > > > >> As the result, after the port was restarted, it showed bogus flow rules. > > > > > > There are two issues, > > > > > > 1) According what I see in the rte_flow documentation, not sure if the "port > > > stop" should clear the rules: > > > " > > > 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. > > > " > > > > > Good catch I think this part should be removed, since it has many issues. The > > application is the only > > one that can be responsible for the rules. > > > > Thinks about the following scenario: application configures 2 queues 0 and 1. > > It insert flow with queue action 1. > > It stops the port and remove queue 1. What should the PMD do? > > What happens if he changed some thing else in configuration that make > > the actions invalid? > > > > For those reason (the description in rte_ethdev.h and the above issues with > > keeping the rules) > > we (Mellanox) modified our code to remove the flows in stop function from the > > device. > > This code was inserted to DPDK in 20.05 release. > > One more reason is that saving the flows also waste a lot of memory > > which is very costly to many applications. > > > > > > > As I tested with i40e, it keeps the rules after stop/start, cc'ing @Jeff, > > > @Beilei & @Qi if this is done intentionally. > > > > > > > > > 2) From the perspective of the testers, users of the testpmd. If they are > > > testing a complex set of filter rules, stopping and starting the port flushing > > > all rules may be troublesome. > > > Since there is explicit command to remove a rte_flow rule or to remove them > > > all, > > > user may prefer to call it when required to delete the rules, instead of this is > > > done implicitly in port stop. > > > > > > Btw, this is based on PMD should handle the rules on stop/start, we need to > > > agree on it first, but even that is not the case, we are in the application > > > domain now and we can apply the rules back again in the 'start' if it serves > > > better to the user. > > > > > First like I said above I think we should agree that it is the application > > responsibility to manage the rules and not the PMD, and first thing to do it > > update the rte_flow doc. > > > > Second I agree that we should discuss if test-pmd should keep the rules and > > reapply them, > > but just like for the PMD the user may create invalid configuration, so re- > > applying the rules > > maybe incorrect. > > Currently test-pmd is not build to support large number of rules, unless using a > > script, and if the user uses a script > > he can reuse this script.