Hi > -----Original Message----- > From: Thomas Monjalon <tho...@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. >
