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

[Thomas Monjalon <thomas@monjalon.net>]

18/01/2023 16:17, Ori Kam:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 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.

The confusion is that we can think of a port on the host.