RE: [PATCH v2 1/2] ethdev: add PHY affinity match item

["Jiawei(Jonny) Wang" <jiaweiw@nvidia.com>]

Hi,

> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: Wednesday, February 1, 2023 4:50 PM
> On 1/30/23 20:00, Jiawei Wang wrote:
> > For the multiple hardware ports connect to a single DPDK port
> > (mhpsdp),
> 
> Sorry, what is mhpsdp?
> 

(m)ultiple (h)ardware (p)orts (s)ingle (D)PDK (p)ort.
It's short name for "multiple hardware ports connect to a single DPDK port".

> > currently, there is no information to indicate the packet belongs to
> > which hardware port.
> >
> > This patch introduces a new phy affinity item in rte flow API, and
> 
> "This patch introduces ..." -> "Introduce ..."
> rte -> RTE
> 

OK.
> > the phy affinity value reflects the physical port of the received packets.
> >
> > While uses the phy affinity as a matching item in the flow, and sets
> > the same phy_affinity value on the tx queue, then the packet can be
> > sent from
> 
> tx -> Tx
> 

OK.
> > the same hardware port with received.
> >
> > This patch also adds the testpmd command line to match the new item:
> > 	flow create 0 ingress group 0 pattern phy_affinity affinity is 1 /
> > 	end actions queue index 0 / end
> >
> > The above command means that creates a flow on a single DPDK port and
> > matches the packet from the first physical port (assume the phy
> > affinity 1
> 
> Why is it numbered from 1, not 0? Anyway it should be defined in the
> documentation below.
> 

While uses the phy affinity as a matching item in the flow, and sets the
same phy_affinity value on the tx queue, then the packet can be sent from
the same hardware port with received. 

So, if the Phy affinity 0 is no affinity then the first value should be 1.


> > stands for the first port) and redirects these packets into RxQ 0.
> >
> > Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
> 
> [snip]
> 
> > diff --git a/doc/guides/rel_notes/release_23_03.rst
> > b/doc/guides/rel_notes/release_23_03.rst
> > index c15f6fbb9f..a1abd67771 100644
> > --- a/doc/guides/rel_notes/release_23_03.rst
> > +++ b/doc/guides/rel_notes/release_23_03.rst
> > @@ -69,6 +69,11 @@ New Features
> >       ``rte_event_dev_config::nb_single_link_event_port_queues`` parameter
> >       required for eth_rx, eth_tx, crypto and timer eventdev adapters.
> >
> > +* **Added rte_flow support for matching PHY Affinity fields.**
> 
> Why "Affinity", not "affinity"?
> 

correct, will update.
> > +
> > +  For the multiple hardware ports connect to a single DPDK port
> > + (mhpsdp),  Added ``phy_affinity`` item in rte_flow to support
> > + physical affinity of  the packets.
> 
> Please, add one more empty line to have two before the next section.
> 
OK.
> >
> >   Removed Items
> >   -------------
> 
> [snip]
> 
> > diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index
> > b60987db4b..56c04ea37c 100644
> > --- a/lib/ethdev/rte_flow.h
> > +++ b/lib/ethdev/rte_flow.h
> 
> > @@ -2103,6 +2110,27 @@ static const struct rte_flow_item_meter_color
> rte_flow_item_meter_color_mask = {
> >   };
> >   #endif
> >
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * RTE_FLOW_ITEM_TYPE_PHY_AFFINITY
> > + *
> > + * For the multiple hardware ports connect to a single DPDK port
> > +(mhpsdp),
> > + * use this item to match the physical affinity of the packets.
> > + */
> > +struct rte_flow_item_phy_affinity {
> > +	uint8_t affinity; /**< physical affinity value. */
> 
> Sorry, I'd like to know how application should find out which values may be
> used here? How many physical ports are behind this one DPDK ethdev?
> 

Like Linux bonding scenario, multiple physical port (for example PF1, PF2) can add into bond port as slave role, 
dpdk only probe and attach the bond master port (bond0), so total two phy affinity values. 

PMD can define the phy affinity and mapping the physical port, Or I can document the numbering in RTE level.

> Also, please, define which value should be used for the first port 0 or 1. I'd vote
> for 0.

If need to define the affinity numbering, 
I prefer to use 1 for first port, 0 for reserve and can keep the same value as tx side (second patch introduces the tx_phy_affinity).