On 1/30/23 20:00, Jiawei Wang wrote:
For the multiple hardware ports connect to a single DPDK port (mhpsdp),
the previous patch introduces the new rte flow item to match the
phy affinity of the received packets.
This patch adds the tx_phy_affinity setting in Tx queue API, the affinity
"This patch adds" -> "Add ..."
value reflects packets be sent to which hardware port.
Value 0 is no affinity and traffic will be routed between different
physical ports,
Who will it be routed?
if 0 is disabled then try to match on phy_affinity 0
will result in an error.
Why are you talking about matching here?
Adds the new tx_phy_affinity field into the padding hole of rte_eth_txconf
structure, the size of rte_eth_txconf keeps the same. Adds a suppress
type for structure change in the ABI check file.
This patch adds the testpmd command line:
testpmd> port config (port_id) txq (queue_id) phy_affinity (value)
For example, there're two hardware ports 0 and 1 connected to
a single DPDK port (port id 0), and phy_affinity 1 stood for
hardware port 0 and phy_affinity 2 stood for hardware port 1,
used the below command to config tx phy affinity for per Tx Queue:
port config 0 txq 0 phy_affinity 1
port config 0 txq 1 phy_affinity 1
port config 0 txq 2 phy_affinity 2
port config 0 txq 3 phy_affinity 2
These commands config the TxQ index 0 and TxQ index 1 with phy affinity 1,
uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
hardware port 0, and similar with hardware port 1 if sending packets
with TxQ 2 or TxQ 3.
Frankly speaking I dislike it. Why do we need to expose it on
generic ethdev layer? IMHO dynamic mbuf field would be a better
solution to control Tx routing to a specific PHY port.
IMHO, we definitely need dev_info information about a number of
physical ports behind. Advertising value greater than 0 should
mean that PMD supports corresponding mbuf dynamic field to
contol ongoing physical port on Tx (or should just reject
packets on prepare which try to specify outgoing phy port
otherwise). In the same way the information may be provided
on Rx.
I'm OK to have 0 as no phy affinity value and greater than
zero as specified phy affinity. I.e. no dynamic flag is
required.
Also I think that order of patches should be different.
We should start from a patch which provides dev_info and
flow API matching and action should be in later patch.
Signed-off-by: Jiawei Wang <jiaw...@nvidia.com>
[snip]
