On Wed, Jun 3, 2020 at 1:53 PM Jerin Jacob [off-list ref] wrote:

On Wed, May 20, 2020 at 2:48 PM Andrey Vesnovaty
[off-list ref] wrote:

quoted

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

quoted

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

quoted

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

quoted

(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.