[dpdk-dev] [PATCH v2 1/4] ethdev: introduce indirect action APIs
Andrew Rybchenko
andrew.rybchenko at oktetlabs.ru
Thu Apr 15 18:02:16 CEST 2021
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 <bingz at nvidia.com>
>>
>> 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.
More information about the dev
mailing list