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 <bi...@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.
