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 200B5A0524; Mon, 12 Apr 2021 21:42:21 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A382114130E; Mon, 12 Apr 2021 21:42:20 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mails.dpdk.org (Postfix) with ESMTP id 3F46D141309 for ; Mon, 12 Apr 2021 21:42:18 +0200 (CEST) IronPort-SDR: DVDbH7mkjuzXDalfIVJsS3bJwwEFe4PyWWmXCJDx2jjZTvdlcv+5wQ4/vvPuYjE7ddO03NWJla P9GhZBDFOaGg== X-IronPort-AV: E=McAfee;i="6200,9189,9952"; a="279567282" X-IronPort-AV: E=Sophos;i="5.82,216,1613462400"; d="scan'208";a="279567282" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Apr 2021 12:42:17 -0700 IronPort-SDR: /d3WFIVpR2L/PiLfJonp+Bs7JltXqnHMhtpswth5x+dAY24XXiDeRXrgvZAuM2Zlj+uNSUzzFf sTwnXhNQUtAA== X-IronPort-AV: E=Sophos;i="5.82,216,1613462400"; d="scan'208";a="460291976" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.203.254]) ([10.213.203.254]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Apr 2021 12:42:14 -0700 To: Bing Zhao , orika@nvidia.com, thomas@monjalon.net, andrew.rybchenko@oktetlabs.ru, matan@nvidia.com, viacheslavo@nvidia.com Cc: 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-1-git-send-email-bingz@nvidia.com> <1618063428-206842-2-git-send-email-bingz@nvidia.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <728b94bb-b5fa-37bd-ecc8-411fcac1465f@intel.com> Date: Mon, 12 Apr 2021 20:42:13 +0100 MIME-Version: 1.0 In-Reply-To: <1618063428-206842-2-git-send-email-bingz@nvidia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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/10/2021 3: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 > --- > doc/guides/rel_notes/release_21_05.rst | 3 + > lib/librte_ethdev/rte_flow.c | 56 ++++++++-------- > lib/librte_ethdev/rte_flow.h | 118 +++++++++++++++++++-------------- > lib/librte_ethdev/rte_flow_driver.h | 26 ++++---- > lib/librte_ethdev/version.map | 8 +-- Isn't there any documentation to update with this change? If the shared action API is not documented at all, can you please add documentation for the action handle API?