From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 77AFCA0C3F; Thu, 15 Apr 2021 16:10:51 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5D77D161CA0; Thu, 15 Apr 2021 16:10:51 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 34D21161C88 for ; Thu, 15 Apr 2021 16:10:50 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 941EB5C019D; Thu, 15 Apr 2021 10:10:49 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 15 Apr 2021 10:10:49 -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=fm3; bh= Ih3v9dmwA7hnaLyrDCfZouiVGO2LT3GtuXNVWrdZEXU=; b=h8g9c25izxXKDF3u +p6SuGACiyysPqSwcm7k1rKrW5YBkfQevwjVUJg+JeD+9QpafdwNWSXtsrYLK2ZN WXIBDcuomzTSgCfu9VpIpmpkhsSDxNGSS959h5ieL8Upf5i/j1OKbCm/Jy3KF8n0 X6Csf1okZa56G9UvnIw5iWIfOFjrnUw1vumh7GGR9vT2iHKvhDQDid25lPfszxOs csSdiMjuElOpej10itfXVtNfth+33WG6TGupakCp1ZwbSDDdRDIOXQ3Nt+4xL3TZ qXCiueWg8m+h6JsV8FvclnIx07WdJg+bfFZAA6ZF3aH79BISP2IqycB17Wsc0OPN 3MP54w== 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=fm2; bh=Ih3v9dmwA7hnaLyrDCfZouiVGO2LT3GtuXNVWrdZE XU=; b=kbgi5sJkz0sVo1w9kyDhF/vfyRH+h9rGCkoe++gROu5b4uz/yfVHI3XA2 PufmDd8WMuRvtsNdIddz4seKKoTiYHS4KPuOwHCommCaazAG8bhbPgyclQQoUwr+ T+zY0RIB6YgmQEfy+8Y46qTEDqUI5f304AunhbJZ7h31/2wKCB55Z5L2+yAXImXz vypTMHhF27VSEGZiTb+NXuBndLRw6WBfm0sn7t3s0aICex2V9hZt6ydgCPYLqTEF hRoVT0gj7I6ypQpPszbX2yeoa4rdP23FlnA8gAxahLYHX8ZmpqMkqvMLV1yum8Cd gXxJYEeNAG3nG9+zr2TvV0ye5IG1A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudelfedgjeejucetufdoteggodetrfdotf 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 7B4E71080057; Thu, 15 Apr 2021 10:10:47 -0400 (EDT) From: Thomas Monjalon To: Bing Zhao , Andrew Rybchenko Cc: orika@nvidia.com, ferruh.yigit@intel.com, matan@nvidia.com, viacheslavo@nvidia.com, dev@dpdk.org, ajit.khaparde@broadcom.com, getelson@nvidia.com, andreyv@nvidia.com Date: Thu, 15 Apr 2021 16:10:44 +0200 Message-ID: <1948840.NBh1U2Dmfe@thomas> In-Reply-To: <2cf0227d-e070-1d01-af68-1cdf6a6ea0ef@oktetlabs.ru> References: <1617940481-125528-1-git-send-email-bingz@nvidia.com> <1618063428-206842-2-git-send-email-bingz@nvidia.com> <2cf0227d-e070-1d01-af68-1cdf6a6ea0ef@oktetlabs.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 1/4] ethdev: introduce indirect action APIs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" 15/04/2021 15:55, Andrew Rybchenko: > On 4/10/21 5:03 PM, Bing Zhao wrote: > > Right now, rte_flow_shared_action_* APIs are used for some shared > > actions, like RSS, count. The shared action should be created before > > using it inside a flow. These shared actions sometimes are not > > really shared but just some indirect actions decoupled from a flow. > > > > The new functions rte_flow_action_handle_* are added to replace > > the current shared functions rte_flow_shared_action_*. > > > > There are two types of flow actions: > > 1. the direct (normal) actions that could be created and stored > > within a flow rule. Such action is tied to its flow rule and > > cannot be reused. > > 2. the indirect action, in the past, named shared_action. It is > > created from a direct actioni, like count or rss, and then used > > in the flow rules with an object handle. The PMD will take care > > of the retrieve from indirect action to the direct action > > when it is referenced. > > > > The indirect action is accessed (update / query) w/o any flow rule, > > just via the action object handle. For example, when querying or > > resetting a counter, it could be done out of any flow using this > > counter, but only the handle of the counter action object is > > required. > > The indirect action object could be shared by different flows or > > used by a single flow, depending on the direct action type and > > the real-life requirements. > > The handle of an indirect action object is opaque and defined in > > each driver and possibly different per direct action type. > > > > The old name "shared" is improper in a sense and should be replaced. > > > > All the command lines in testpmd application with "shared_action*" > > are replaced with "indirect_action*". > > > > The parameter of "update" interface is also changed. A general > > pointer will replace the rte_flow_action struct pointer due to the > > facts: > > 1. Some action may not support fields updating. In the example of a > > counter, the only "update" supported should be the reset. So > > passing a rte_flow_action struct pointer is meaningless and > > there is even no such corresponding action struct. What's more, > > if more than one operations should be supported, for some other > > action, such pointer parameter may not meet the need. > > 2. Some action may need conditional or partial update, the current > > parameter will not provide the ability to indicate which part(s) > > to update. > > For different types of indirect action objects, the pointer could > > either be the same of rte_flow_action* struct - in order not to > > break the current driver implementation, or some wrapper > > structures with bits as masks to indicate which part to be > > updated, depending on real needs of the corresponding direct > > action. For different direct actions, the structures of indirect > > action objects updating will be different. > > > > All the underlayer PMD callbacks will be moved to these new APIs. > > > > The RTE_FLOW_ACTION_TYPE_SHARED is kept for now in order not to > > break the ABI. All the implementations are changed by using > > RTE_FLOW_ACTION_TYPE_INDIRECT. > > > > Signed-off-by: Bing Zhao > > Just for the record. I still dislike renaming since "shared" highlights > purpose (what is definitely better), but "indirect" is just a technical > detail on how it is done. The difference is that indirect action is not only for sharing. It allows manipulating an action as an object. Action object is inserted in flow rules through the indirect action. Does it make it clearer?