Re: [RFC 1/5] ethdev: add port affinity match item

[Thomas Monjalon <thomas@monjalon.net>]

18/01/2023 15:41, Jiawei(Jonny) Wang:
> Hi,
> 
> > 
> > 21/12/2022 11:29, Jiawei Wang:
> > > +	/**
> > > +	 * Matches on the physical port affinity of the received packet.
> > > +	 *
> > > +	 * See struct rte_flow_item_port_affinity.
> > > +	 */
> > > +	RTE_FLOW_ITEM_TYPE_PORT_AFFINITY,
> > >  };
> > 
> > I'm not sure about the word "affinity".
> > I think you want to match on a physical port.
> > It could be a global physical port id or an index in the group of physical ports
> > connected to a single DPDK port.
> > In first case, the name of the item could be RTE_FLOW_ITEM_TYPE_PHY_PORT,
> > in the second case, the name could be
> > RTE_FLOW_ITEM_TYPE_MHPSDP_PHY_PORT,
> > "MHPSDP" meaning "Multiple Hardware Ports - Single DPDK Port".
> > We could replace "PHY" with "HW" as well.
> >
> 
> Since DPDK only probe/attach the single port, seems first case does not meet this case.
> Here, 'affinity' stands for the packet association with actual physical port.

I think it is more than affinity because the packet is effectively
received from this port.
And the other concern is that this name does not give any clue
that we are talking about multiple ports merged in a single one.

> > Note that we cannot use the new item
> > RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
> > because we are in a case where multiple hardware ports are merged in a single
> > software represented port.
> > 
> > 
> > [...]
> > > +/**
> > > + * @warning
> > > + * @b EXPERIMENTAL: this structure may change without prior notice
> > > + *
> > > + * RTE_FLOW_ITEM_TYPE_PORT_AFFINITY
> > > + *
> > > + * For the multiple hardware ports connect to a single DPDK port
> > > +(mhpsdp),
> > > + * use this item to match the hardware port affinity of the packets.
> > > + */
> > > +struct rte_flow_item_port_affinity {
> > > +	uint8_t affinity; /**< port affinity value. */ };
> > 
> > We need to define how the port numbering is done.
> > Is it driver-dependent?
> > Does it start at 0? etc...
> 
> User can define any value they want; one use case is the packet could be received and
> sent to same port, then they can set the same 'affinity' value in flow and queue configuration.

No it does not work.
If ports are numbered 1 and 2, and user thinks it is 0 and 1,
the port 2 won't be matched at all.

> The flow behavior is driver dependent.
> 
> Thanks.