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

Adrian Schollmeyer a.schollmeyer at syseleven.de
Wed Mar 25 14:04:32 CET 2026


Hi,

Am Dienstag, dem 24.03.2026 um 09:04 +0000 schrieb Dariusz Sosnowski:
> 
> Adrian: Could you please elaborate what kind of issues have you faced
> with shared queue configuration?

For one, I find the documentation around shared Rx queues quite poor to
begin with. Back then, I tried to make it work on a regular ConnectX-6
NIC with multiple VFs. For lack of better understanding, I just tried
to run testpmd to check whether shared Rx queues works with this kind
of setup. Unfortunately, testpmd neither emitted a warning/error
message nor was able to set up the queues properly. Instead, everything
failed silently. It may very well have been me just using the feature
wrong, but testpmd did nothing to help me debug the issue.

Unfortunately, I am not working on this topic anymore, so I have no
recent experience with similar issues which I could provide. Also, as I
did this quite some time ago, I cannot remember all the details.

> > 
> > 
> Based on current implementation in ethdev and mlx5 PMD,
> assuring that share group indexes are unique is not needed.
> Share group index is not required to be globally unique since
> sharing works only within the same switch and Rx domain [1].

So if I understand this correctly, it is correct behavior for DPDK to
silently accept the same share_group and qid for ports on different
domains?

From a user perspective, I see two issues here:

* The rx_domain and domain_id values are obscure magic values, whose
  meaning is neither obvious nor very well documented. Therefore, in my
  opinion, users cannot be expected to "just know" what they imply and
  and where they might be different.

  My personal assumption was that they probably differ from NIC to
  NIC or possibly from PF to PF, but from what I learned while
  experimenting with that ConnectX-6 NIC, this doesn't necessarily
  seem to be the case.

* Using the same share_group for two Rx queues intuitively means that
  they are shared. Since this feature is used to combine Rx paths
  across ports, I would expect that the identifiers are valid across
  ports, not switch domains or Rx domains. In my opinion, this is
  highly unintuitive from a user's perspective and I would expect DPDK 
  to assume that the same share group ID actually means trying to use
  the same share group, no matter which ports are combined.

Therefore, I would prefer requiring uniqueness of share group IDs
across all ports. In any case, the shared Rx queue feature could
probably benefit from improved documentation.

Best regards
Adrian


-- 
Adrian Schollmeyer

SysEleven GmbH 
Boxhagener Straße 80 
10245 Berlin 

T +49 30 / 23 32 012-0
F +49 30 / 61 67 55 5-0 

https://www.syseleven.de 
https://www.linkedin.com/company/syseleven-gmbh

Current system status always at: 
https://www.syseleven-status.net/ 

Company headquarters: Berlin 
Registered court: AG Berlin Charlottenburg, HRB 108571 Berlin 
Managing directors: Andreas Hermann, Jens Ihlenfeld, Jens Plogsties,
Andreas Rückriegel


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mails.dpdk.org/archives/dev/attachments/20260325/8e60ff80/attachment.sig>


More information about the dev mailing list