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.
> 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.
The flow behavior is driver dependent.
Thanks.
