Re: [dpdk-dev] [RFC] add flow action context API

[Andrey Vesnovaty <andrey.vesnovaty@gmail.com>]

On Wed, Jun 3, 2020 at 1:53 PM Jerin Jacob <jerinjacobk@gmail.com> wrote:

> On Wed, May 20, 2020 at 2:48 PM Andrey Vesnovaty
> <andrey.vesnovaty@gmail.com> wrote:
> >
> > This commit introduces extension of DPDK flow action API enabling
> > modification of single rte_flow_action.
> >
> > Motivation and example
> > ===
> > Adding or removing one or more queues to RSS actions cloned in 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
> >
> > In order to prevent the overhead of multiple RSS flow rules
> reconfiguration
> > API for in-place flow action modification introduced in this commit.
> >
> > Change description
> > ===
> > Provide an API to create single rte_flow_action context to
> point/reference
> > rte_flow_action object contents from multiple rte_flow_rule objects.
> > Actually the introduced API makes action object shared and modification
> > of such an action effects all the rules referencing the action via
> context
> > (see struct rte_flow_action_ctx).
> >
> > Action context lifetime
> > ---
> > Once action context created (see rte_flow_action_ctx_create()) it can be
> > safely reused for:
> > - new flow rule creation
> > - action configuration/state modification
> >   (see rte_flow_action_ctx_modify())
> > - action state query (see rte_flow_action_ctx_query())
> > Once rte_flow_action_ctx_destroy() called the destroyed action context
> > should not be used i.e. result of the usage undefined.
>
> Motivation makes sense to me. It will be an improvement.
>
> But creating shared objects adds additional complexity to "PMD and
> application" as it
> needs to manage the state. Since rte_flow_action already expressed in
> vendor natural format,  What will be the benefit of a shared context?
>
> The benefit (or goal of the proposed API extension) is to modify the
behaviour of multiple flows by single API call.


> Would the following additional API suffice the motivation?
>
> rte_flow_modify_action(struct rte_flow * flow,  const struct
> rte_flow_action actions[])
>

This API limits the scope to single flow which isn't the goal for the
proposed change.