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 C172AA0C3F; Thu, 15 Apr 2021 18:02:19 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 54A161623C2; Thu, 15 Apr 2021 18:02:19 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 93C8F1623BF for ; Thu, 15 Apr 2021 18:02:17 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id F3B2E7F527; Thu, 15 Apr 2021 19:02:16 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru F3B2E7F527 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1618502537; bh=xeCY/cU1HZMC0KG+sCgk3AjltZuQ3MbklYPV7pGB+1U=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=PqJ+U4HlCM5sinbEw5Qb6k6kNW3u/IJwG9g5rUznK9LMJZo4Gpi1mUXjKhR3dL0D8 ZtS5vr47eKu8yU2DlGoajaevne7RAsV5GD8YZh2Rqp5adNHI+FoAAHnjxl8KX18QLf +WonF4m3lQzpfF+ktgKaFEwonU8/W9NS5GOrbC30= To: Thomas Monjalon , Bing Zhao 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 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> <1948840.NBh1U2Dmfe@thomas> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: Date: Thu, 15 Apr 2021 19:02:16 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <1948840.NBh1U2Dmfe@thomas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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" On 4/15/21 5:10 PM, Thomas Monjalon wrote: > 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? > Yes, I see thanks.