[PATCH v3] app/testpmd: fail on shared rxq switch mismatch

[Dariusz Sosnowski]

Hi all,

On Mon, Dec 01, 2025 at 11:22:11AM +0100, a.schollmeyer at syseleven.de wrote:
> From: Adrian Schollmeyer <a.schollmeyer at syseleven.de>
> 
> Shared Rx queues do not work with every combination of ports. Besides
> requiring the corresponding device capability, shared Rx queues also
> require all ports of one share group and queue ID have the same switch
> domain and Rx domain. When these fields do not match, shared Rx queues
> are not properly set up and queue sharing may fail silently. This can
> happen even in some less intuitive cases like multiple VFs of one
> physical NIC and may cause packets not to be read by the application,
> depending on how the data path is implemented.
> 
> To help with debugging issues with shared Rx queue configuration when
> using testpmd, this commit introduces simple checks and error messages
> for members of a share_group and share_qid to fail whenever there is a
> mismatch in the switch and Rx domain.
> 
> Signed-off-by: Adrian Schollmeyer <a.schollmeyer at syseleven.de>

Our internal regression tests have flagged issues with shared Rx queues.
Specifically, issues with domain mismatches:

	Invalid shared rxq config: switch domain mismatch ports 0 and 3

In my opinion, additional testpmd fixes for shared Rx queues or a revert is needed.
Please find the details below and let me know what you all think.

Best regards,
Dariusz Sosnowski

---

https://github.com/DPDK/dpdk/commit/8ebba91086f47c90e398d7775921e05659c0d62f

**ethdev and mlx5 driver behavior**

In DPDK API, to enable Rx queue sharing,
the application must provide 2 parameters in rte_eth_rxconf struct:

- share_group
- share_qid

2 Rx queues can be shared if and only if these queues are created on
ports which share both switch and Rx domain.
In mlx5 NICs case this means that queues can be shared only between
representors for a single embedded switch.

Both ethdev library and mlx5 driver do not explicitly require that
share group index is globally unique.
The same value of share_group index can be used in different domains.
For example, the following is allowed:

- port 1, switch/Rx domain 1, share_group index == 1
- port 2, switch/Rx domain 2, share_group index == 1

In this case, both share groups are considered unique and separate
because they are set up in different domains.

**testpmd**

--rxq-share parameter can be used in 2 ways:

- --rxq-share=N - Set of ports is divided into subsets, each with N
  ports. Each subset gets new share group index.
  Index is assigned incrementally based on port index.
- --rxq-share - Same as N=UINT32_MAX. In practice this means
  that all ports get the same share group index equal to 1.

In our internal testing, where combination of sharing Rx queues
and dynamic representor attachment was tested,
"--rxq-share" parameter was used.
These tests relied on assigning the same group index to each shared queue.
When new representors were probed, their queues were added to existing
share groups.

After this patch was applied it is no longer possible,
regardless of the --rxq-share option variant used:

- Without additional N parameter - probing 2 different PFs and
  configuring shared queues failes on mismatch.
- With additional N parameter - queues of dynamically added representors
  cannot be added to existing share groups.

**Possible solutions**

For now, I see 2 possible ways to resolve it:

1. testpmd assigns unique share group index per domain:
    - Behavior change for --rxq-share parameter.
    - Instead of statically assigning indexes based on port index,
      testpmd will internally allocate new share group index
      per unique switch and Rx domain.
    - Drop additional parameter N for --rxq-share.
2. Expand testpmd parameters for shared Rx queues:
    - Allow explicit assignment of share group index through additional
      parameters.
    - Right now, it's unclear how to handle dynamic port attachment in
      this solution.