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 80625A04B7; Wed, 14 Oct 2020 09:22:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CD0521DC89; Wed, 14 Oct 2020 09:22:43 +0200 (CEST) Received: from wnew4-smtp.messagingengine.com (wnew4-smtp.messagingengine.com [64.147.123.18]) by dpdk.org (Postfix) with ESMTP id 04EA51DC88 for ; Wed, 14 Oct 2020 09:22:42 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.west.internal (Postfix) with ESMTP id 3EA785A6; Wed, 14 Oct 2020 03:22:39 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 14 Oct 2020 03:22:40 -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= XsZexe/I3nCFNXVCgR5CNokgp6+akZSCP9LNdFO40ow=; b=q4949GFyhdDqHsVf uevEN1KuTSobau4S+sOZNugSgzwOUPriL7rodz/ZHMkcuNaPRxWUgNslNet+5ZFJ cc0NCJUATZH4WejS0Ml5DQRI/eCtYhJM6ipVwXL+P6j2rEre+PyhNVQlYfvnoG2D pWHH+S/S88TnlNyDYSWxek+CvUs7ZgUos6W6HXipD0IOBebkSqkAe5bkgEYKwR2F XsfQ+Tj/Tugf0jD8oAIj0cR9yR+KQkY2YBnjb29eaYFFc6xSvYoTcNDTrNi7TrGM 5xUVeAKgxCEWzxR/jcCIUifvGalYKF3zGwmo7gdUcWsrCUuJ+ApMm4yg6v8stF+O dAzQ7g== 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=XsZexe/I3nCFNXVCgR5CNokgp6+akZSCP9LNdFO40 ow=; b=gHXmFBvK/Z1ZenuleRjHUQFW4dRLPAA4oge0+mHO27RdMYIfbRjBpWM6B aTQuQPjAqxL4pga+7MKkkz9FBEE0f1h0TzKUUh81Yx7GEcCCfLClNq7VX2uofr7Y KqI2RTZ4isbUgnS28EdyOWLVeWp2IGNXC7S8Mx5XJ5gRvOmaDXT9CG9QHnTkgj1A 2OUM5I5XOWlRb4DddrRWtJP2iVeQ4wCKWTrSACcCxDsku7NuS3jYYXPi5Y/ATKCt K6Hf+0QC4p3+5Hc+/uHSPNn+baItzR4ehVB4V4M7HL1zdzdjLG8bWRTK/NAtm+hY 4NC5CijBoljloW/ClTH9nx34akMMw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedriedtgdduvdduucetufdoteggodetrfdotf 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 E003F3064680; Wed, 14 Oct 2020 03:22:36 -0400 (EDT) From: Thomas Monjalon To: Andrey Vesnovaty Cc: "dev@dpdk.org" , Andrew Rybchenko , jerinj@marvell.com, "ferruh.yigit@intel.com" , "stephen@networkplumber.org" , "bruce.richardson@intel.com" , Ori Kam , Slava Ovsiienko , "andrey.vesnovaty@gmail.com" , "ajit.khaparde@broadcom.com" , "samik.gupta@broadcom.com" Date: Wed, 14 Oct 2020 09:22:35 +0200 Message-ID: <1884452.bCSgJj8pPL@thomas> In-Reply-To: References: <20200702120511.16315-1-andreyv@mellanox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v7 1/2] ethdev: add flow shared action API 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" 14/10/2020 08:49, Andrew Rybchenko: > On 10/13/20 11:06 PM, Andrey Vesnovaty wrote: > > From: Andrew Rybchenko > >>> Shared action create/use/destroy > >>> === > >>> Shared action may be reused by some or none flow rules at any given > >>> moment, i.e. shared action resides outside of the context of any flow. > >>> Shared action represent HW resources/objects used for action offloading > >>> implementation. > >>> API for shared action create (see `rte_flow_shared_action_create()`): > >>> - should allocate HW resources and make related initializations required > >>> for shared action implementation. > >>> - make necessary preparations to maintain shared access to > >>> the action resources, configuration and state. > >>> API for shared action destroy (see `rte_flow_shared_action_destroy()`) > >>> should release HW resources and make related cleanups required for shared > >>> action implementation. > >>> > >>> In order to share some flow action reuse the handle of type > >>> `struct rte_flow_shared_action` returned by > >>> rte_flow_shared_action_create() as a `conf` field of > >>> `struct rte_flow_action` (see "example" section). > >>> > >>> If some shared action not used by any flow rule all resources allocated > >>> by the shared action can be released by rte_flow_shared_action_destroy() > >>> (see "example" section). The shared action handle passed as argument to > >>> destroy API should not be used any further i.e. result of the usage is > >>> undefined. > >>> > >>> Shared action re-configuration > >>> === > >>> Shared action behavior defined by its configuration can be updated via > >>> rte_flow_shared_action_update() (see "example" section). The shared > >>> action update operation modifies HW related resources/objects allocated > >>> on the action creation. The number of operations performed by the update > >>> operation should not depend on the number of flows sharing the related > >>> action. On return of shared action update API action behavior should be > >>> according to updated configuration for all flows sharing the action. > >>> > >>> Shared action query > >>> === > >>> Provide separate API to query shared action state (see > >>> rte_flow_shared_action_update()). Taking a counter as an example: query > >>> returns value aggregating all counter increments across all flow rules > >>> sharing the counter. This API doesn't query shared action configuration > >>> since it is controlled by rte_flow_shared_action_create() and > >>> rte_flow_shared_action_update() APIs and no supposed to change by other > >>> means. > >>> > >>> PMD support > >>> === > >>> The support of introduced API is pure PMD specific design and > >>> responsibility for each action type (see struct rte_flow_ops). This sentence is strange. Of course PMD implementation is a PMD specific design. I think you can remove it. > >>> testpmd > >>> === > >>> In order to utilize introduced API testpmd cli may implement following > >>> extension > >>> create/update/destroy/query shared action accordingly > >>> > >>> flow shared_action (port) create {action_id (id)} (action) / end > >>> flow shared_action (port) update (id) (action) / end > >>> flow shared_action (port) destroy action_id (id) {action_id (id) [...]} > >>> flow shared_action (port) query (id) > >>> > >>> testpmd example > >>> === > >>> > >>> configure rss to queues 1 & 2 > >>> > >>>> flow shared_action 0 create action_id 100 rss queues 1 2 end / end > >>> > >>> create flow rule utilizing shared action > >>> > >>>> flow create 0 ingress \ > >>> pattern eth dst is 0c:42:a1:15:fd:ac / ipv6 / tcp / end \ > >>> actions shared 100 / end > >>> > >>> add 2 more queues > >>> > >>>> flow shared_action 0 modify 100 rss queues 1 2 3 4 end / end > >> > >> testpmd is out-of-scope of the patch and it is better to > >> remove the description to avoid unsync if testpmd > >> commands are changed. > > > > There is still added value is testpmd example demonstrating usage of > > shared action with rte flows. I will update the example to reflect the current > > testpmd syntax for shared action. > > Yes and no. IMHO It would be OK for series description etc, > but not OK for the changeset description which will be > kept in the history and will become misleading when > commands are changed. I think that no information is better > than potentially wrong information. I agree with Andrew, the API explanation should be enough. Talking about testpmd commands in the ethdev patch is not appropriate.