On Wed, Jun 3, 2020 at 1:53 PM Jerin Jacob <jerinjac...@gmail.com> wrote:
> On Wed, May 20, 2020 at 2:48 PM Andrey Vesnovaty > <andrey.vesnov...@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.
