On 2/7/2023 2:01 PM, Viacheslav Ovsiienko wrote: > The RTE Flow API implements the concept of shared objects, > known as indirect actions (RTE_FLOW_ACTION_TYPE_INDIRECT). > An application can create the indirect action of desired > type and configuration with rte_flow_action_handle_create > call and then specify the obtained action handle in multiple > flows. > > The initial concept supposes the action handle has strict > attachment to the port it was created on and to be used > exclusively in the flows being installed on the port. > > Nowadays the multipath network topologies are quite common, > packets belonging to the same connection might arrive and > be sent over multiple ports, and there is the raising demand > to handle these "spread" connections. To fulfil this demand > it is proposed to extend indirect action sharing across the > multiple ports. This kind of sharing would be extremely useful > for the meters and counters, allowing to manage the single > connection over the multiple ports. > > This cross-port object sharing is hard to implement in > generic way merely with software on the upper layers, but > can be provided by the driver over the single hardware > instance, where multiple ports reside on the same physical > NIC and share the same hardware context. > > To allow this action sharing application should specify > the "host port" during flow configuring to claim the intention > to share the indirect actions. All indirect actions reside within > "host port" context and can be shared in flows being installed > on the host port and on all the ports referencing this one. > > If sharing between host and port being configured is not supported > the configuration should be rejected with error. There might be > multiple independent (mutual exclusive) sharing domains with > dedicated host and referencing ports. > > To manage the shared indirect action any port from sharing domain > can be specified. To share or not the created action is up to > application, no API change is needed. > > Signed-off-by: Viacheslav Ovsiienko <viachesl...@nvidia.com>
Hi Viacheslav, This set doesn't compile, it fails because of some undefined variable/macro in driver code. By any chance can this patch based some internal code? Do you want to separate ethdev and driver patches into different sets, so ehtdev part can go into next-net and driver part can be merged to mlx tree afterwards.
