[dpdk-dev] [RFC] ethdev: introduce action context APIs

[Bing Zhao]

Hi Andrew,

Thanks for your comments.

> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko at oktetlabs.ru>
> Sent: Monday, March 22, 2021 11:00 PM
> To: Bing Zhao <bingz at nvidia.com>; NBU-Contact-Thomas Monjalon
> <thomas at monjalon.net>
> Cc: Ori Kam <orika at nvidia.com>; ferruh.yigit at intel.com; dev at dpdk.org
> Subject: Re: [RFC] ethdev: introduce action context APIs
> 
> External email: Use caution opening links or attachments
> 
> 
> On 3/17/21 7:10 PM, Bing Zhao wrote:
> > Hi Thomas,
> >
> >> -----Original Message-----
> >> From: Thomas Monjalon <thomas at monjalon.net>
> >> Sent: Wednesday, March 17, 2021 4:29 PM
> >> To: Bing Zhao <bingz at nvidia.com>
> >> Cc: Ori Kam <orika at nvidia.com>; ferruh.yigit at intel.com;
> >> andrew.rybchenko at oktetlabs.ru; dev at dpdk.org
> >> Subject: Re: [RFC] ethdev: introduce action context APIs
> >>
> >> External email: Use caution opening links or attachments
> >>
> >>
> >> 17/03/2021 08:59, Bing Zhao:
> >>> The new functions rte_flow_action_ctx* that were added will
> >> replace
> >>> the curret shared functions rte_flow_shared_action_*.
> >>>   - rte_flow_shared_action_create
> >>>   - rte_flow_shared_action_destroy
> >>>   - rte_flow_shared_action_update
> >>>   - rte_flow_shared_action_query
> >>>   + rte_flow_action_ctx_create
> >>>   + rte_flow_action_ctx_destroy
> >>>   + rte_flow_action_ctx_update
> >>>   + rte_flow_action_ctx_query
> >>>
> >>> When creating a action context, it could be shared among
> different
> >>> flows or different ports. Or it could also be used by a single
> >> flow.
> >>> The name "shared" is improper in a sense.
> >>
> >> Is it the only reason for the change?
> >> I better understand "shared" even if it is sometimes not shared.
> >
> > Another reason is as written in the description of commit message,
> currently the update interface use the rte_flow_action as the input
> parameter. It would limit the ability of updating, since
> rte_flow_action only have the "conf" w/o any mask or flag bits.
> >
> > If only part of the fields need to be updated, it couldn't meet
> the needs.
> 
> Sorry, it is too vague. Context in the RFC looks insufficient to
> understand it. Please, provide more details and real-life examples.

Take the next RFC of "conntrack" for example, in the actions structure definition, there are more than a dozen of fields to define the action itself. When an updating is required, sometimes, only part of these fields need to be updated.
__rte_experimental
int
rte_flow_shared_action_update(uint16_t port_id,
			      struct rte_flow_shared_action *action,
			      const struct rte_flow_action *update,
			      struct rte_flow_error *error);
In the current API, the 3rd input parameter "update" has the same struct type "rte_flow_action", and unlike the "rte_flow_item", no "mask" field is contained in the action struct, only "conf". When doing a update, the software has to take all the information pointed by the "conf" and do a whole update. The partial update couldn't be supported with the current update interface definition.
By changing the pointer type from "const struct rte_flow_action *" to the " const void *", it would be much more flexible.
1. For the current implementation that "update" interface has already been used, only a minor change in the PMD is needed, to cast the generic pointer to the action pointer before getting the new "conf".
2. For the new actions implementation that will use the "update" interface, the pointer type will be depends on the need. If no partial is required, it could be the same as before, a action pointer. Or else, a wrapper structure pointer will be used to indicate which field(s) inside to update.
I hope this description would be a bit more detailed about the purpose of this change.

And since the "update" interface needs to be updated, we could change the other 3 interfaces with proper names. What do you think?

BR. Bing