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 AE370A04DB; Wed, 14 Oct 2020 18:18:03 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8C24B1D6F1; Wed, 14 Oct 2020 18:18:02 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 779861D442 for ; Wed, 14 Oct 2020 18:18:01 +0200 (CEST) IronPort-SDR: UXxHj9S+dfMxR/n5H6pLLzOnwczDS434EoNuzruRao/bj2moAxdVAQxOwgf+KRrz9M9WmYtblb TvU7EQNgcGKw== X-IronPort-AV: E=McAfee;i="6000,8403,9773"; a="166202431" X-IronPort-AV: E=Sophos;i="5.77,375,1596524400"; d="scan'208";a="166202431" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2020 09:17:59 -0700 IronPort-SDR: v4tQmo6qoil5oz0Nvev9ZGdE2Y2LJMp6iKMvkFuLS1LIWKepGOlMZciASjpdJXX+DyatEQfID4 3pEfeehUvj6w== X-IronPort-AV: E=Sophos;i="5.77,375,1596524400"; d="scan'208";a="463939991" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.212.224]) ([10.213.212.224]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2020 09:17:55 -0700 To: Andrew Rybchenko , Andrey Vesnovaty , dev@dpdk.org Cc: jer@marvell.com, jerinjacobk@gmail.com, thomas@monjalon.net, stephen@networkplumber.org, bruce.richardson@intel.com, orika@nvidia.com, viacheslavo@nvidia.com, andrey.vesnovaty@gmail.com, mdr@ashroe.eu, nhorman@tuxdriver.com, ajit.khaparde@broadcom.com, samik.gupta@broadcom.com References: <20200702120511.16315-1-andreyv@mellanox.com> <20201014114015.17197-1-andreyv@nvidia.com> <20201014114015.17197-2-andreyv@nvidia.com> From: Ferruh Yigit Message-ID: <14291dec-21ef-3ebf-4e0e-bfe9d6ccf035@intel.com> Date: Wed, 14 Oct 2020 17:17:51 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v8 1/2] ethdev: add shared actions to flow 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" On 10/14/2020 12:44 PM, Andrew Rybchenko wrote: > On 10/14/20 2:40 PM, Andrey Vesnovaty wrote: >> Introduce extension of flow action API enabling sharing of single >> rte_flow_action in multiple flows. The API intended for PMDs, where >> multiple HW offloaded flows can reuse the same HW essence/object >> representing flow action and modification of such an essence/object >> affects all the rules using it. >> >> Motivation and example >> === >> Adding or removing one or more queues to RSS used by multiple flow rules >> imposes per rule toll for current DPDK flow API; the scenario requires >> for each flow sharing cloned RSS action: >> - call `rte_flow_destroy()` >> - call `rte_flow_create()` with modified RSS action >> >> API for sharing action and its in-place update benefits: >> - reduce the overhead of multiple RSS flow rules reconfiguration >> - optimize resource utilization by sharing action across multiple >> flows >> >> Change description >> === >> >> Shared action >> === >> In order to represent flow action shared by multiple flows new action >> type RTE_FLOW_ACTION_TYPE_SHARED is introduced (see `enum >> rte_flow_action_type`). >> Actually the introduced API decouples action from any specific flow and >> enables sharing of single action by its handle across multiple flows. >> >> 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. >> >> example >> === >> >> struct rte_flow_action actions[2]; >> struct rte_flow_shared_action_conf conf; >> struct rte_flow_action action; >> /* skipped: initialize conf and action */ >> struct rte_flow_shared_action *handle = >> rte_flow_shared_action_create(port_id, &conf, &action, &error); >> actions[0].type = RTE_FLOW_ACTION_TYPE_SHARED; >> actions[0].conf = handle; >> actions[1].type = RTE_FLOW_ACTION_TYPE_END; >> /* skipped: init attr0 & pattern0 args */ >> struct rte_flow *flow0 = rte_flow_create(port_id, &attr0, pattern0, >> actions, error); >> /* create more rules reusing shared action */ >> struct rte_flow *flow1 = rte_flow_create(port_id, &attr1, pattern1, >> actions, error); >> /* skipped: for flows 2 till N */ >> struct rte_flow *flowN = rte_flow_create(port_id, &attrN, patternN, >> actions, error); >> /* update shared action */ >> struct rte_flow_action updated_action; >> /* >> * skipped: initialize updated_action according to desired action >> * configuration change >> */ >> rte_flow_shared_action_update(port_id, handle, &updated_action, error); >> /* >> * from now on all flows 1 till N will act according to configuration of >> * updated_action >> */ >> /* skipped: destroy all flows 1 till N */ >> rte_flow_shared_action_destroy(port_id, handle, error); >> >> Signed-off-by: Andrey Vesnovaty >> Acked-by: Ori Kam >> Acked-by: Ajit Khaparde > > Acked-by: Andrew Rybchenko > Series applied to dpdk-next-net/main, thanks.