RE: [RFC] ethdev: sharing indirect actions between ports

[Ori Kam <orika@nvidia.com>]

Hi

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, 18 January 2023 14:07
> 
> 28/12/2022 17:54, Viacheslav Ovsiienko:
> > 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
> 
> I don't like the word "host" because it may refer to the host CPU.
> Also if I understand well, the application must choose one port
> between all ports of the NIC and keep using the same.
> I guess we don't want to create a NIC id.
> So I would suggest to rename to nic_ref_port or something like that.
> 

I think that host is the correct word since this port hosts all resources for other
ports. (this is also why the host is used in case of CPU 😊)
I don't think it is correct to use bad wording due to the fact that some one else
also uses this word. 
in rte_flow we never talk about host CPU so I don't think this is confusing.

> > on the host port and on all the ports referencing this one.
> 
> Not "all the ports" but only on sibling ports (ports of the same NIC).
> 
> > 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.
> [...]
> > +	/**
> > +	 * Port to base shared objects on.
> > +	 */
> > +	uint16_t host_port_id;
> 
> Is it a DPDK ethdev port ID?
> 
> You should add this feature to the release notes and in rte_flow guide.
> 
> PS: please Cc ethdev maintainers.
>