Re: [PATCH 0/8] Validate multiqueue configuration in ethdev

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri, 16 Oct 2026 15:05:46 +0200
David Marchand <david.marchand@redhat.com> wrote:

> We have various checks in drivers about Rx and Tx multiqueue
> configuration.
> This series is a followup of the VMDq cleanup, finishing the job with
> DCB and RSS, and then rejecting invalid multiqueue configuration (useful
> from an ABI point of view).
> 
> Some drivers misreported their capabilities.
> It is important drivers maintainers review carefully those changes.


Thanks, eventually the whole features matrix needs to be auto generated
but that requires lots more work.

First pass of semi-manual AI review found issues

Review: [PATCH 0/8] ethdev multi-queue mode validation (David Marchand)

Applied cleanly on main (v26.11-rc1). Every commit builds with
-Dwerror=true for all touched drivers except mvneta/mvpp2 (no musdk).
All Fixes: hashes resolve.

Main problems: 7/8 rejects RSS mode on ports without RSS, which breaks
in-tree examples and drivers that deliberately tolerated it; and the
devtools trigger added in 4/8 never fires on code changes.


Patch 4/8 devtools: check VMDq capability

Error: has_code_change patterns use '\|' for alternation. git -G
compiles the pattern as ERE, where '\|' is a literal pipe, so it never
matches. On this series:

  git log -G'max_vmdq_pools\|RTE_ETH_MQ_.*VMDQ' HEAD~8..  -> 0 commits
  git log -G'max_vmdq_pools|RTE_ETH_MQ_.*VMDQ'  HEAD~8..  -> 7 commits

So incremental mode only runs check_mq_caps when a features .ini
changes. Use ERE alternation here and in the patterns extended by 5/8
and 7/8:

  if has_code_change 'max_vmdq_pools|RTE_ETH_MQ_.*VMDQ' ||

Warning: drivers under drivers/net/intel/ are never checked.
all_net_drivers and changed_net_drivers only yield "intel", there is no
intel.ini, so check_mq_caps returns early for ixgbe, i40e, igb, ice,
fm10k, ipn3ke, idpf and cpfl, i.e. most VMDq/DCB users. Running the
check over the intel subdirectories reports:

  DCB documented but no get_dcb_info callback for ipn3ke
  RSS documented but flow_type_rss_offloads not set for ipn3ke
  VMDq documented but max_vmdq_pools not set for ipn3ke

e1000 also needs a dir to doc mapping (em/igb/igc share a directory).
igb.ini claims DCB = Y, but igb has no get_dcb_info and 5/8 removes
its "DCB mode is not supported" check. Fix igb.ini and ipn3ke.ini in
this series, and walk drivers/net/intel/*/ in the script.

Info: -S to -G also changes the existing rte_flow trigger.
-S'RTE_FLOW_.*_TYPE_' was a literal match and never fired before.
Mention it in the commit message.


Patch 7/8 ethdev: check RSS availability

Error: rejecting RTE_ETH_MQ_RX_RSS_FLAG when flow_type_rss_offloads is
0 breaks configurations that work today. Applications set RSS mode
statically and only mask rss_hf with flow_type_rss_offloads. In tree:
l3fwd, l3fwd-power, l3fwd-graph, ip_reassembly, distributor, ntb, dma,
eventdev_pipeline, multi_process mp_server, app/graph, test-eventdev.

l3fwd only clears mq_mode for disable_rss or max_rx_queues == 1, so it
now fails rte_eth_dev_configure() on virtio without VIRTIO_NET_F_RSS,
vhost, memif, af_xdp, af_packet, ring and pcap. mp_server uses one Rx
queue with RSS and fails on any port without RSS.

Drivers deliberately accepted this: mvneta (failed only with more than
one Rx queue), octeontx, sfc_repr and cnxk_rep (RSS with one queue and
no hash config). After this patch the RSS branches left in
sfc_repr_check_conf() and rep_eth_conf_chk() are unreachable.

Only reject what cannot work:

	if (dev_info.flow_type_rss_offloads == 0 &&
	    (dev_conf->rxmode.mq_mode & RTE_ETH_MQ_RX_RSS_FLAG) != 0 &&
	    nb_rx_q > 1) {

and fix the examples to drop RSS when the port has none, e.g. l3fwd:

	if (disable_rss == 1 || dev_info.max_rx_queues == 1 ||
	    dev_info.flow_type_rss_offloads == 0)
		local_port_conf.rxmode.mq_mode = RTE_ETH_MQ_RX_NONE;

Update the release note wording to match.


Patch 2/8 drivers/net: fix reported VMDq capability

Warning: Fixes: targets are in released versions but there is no
Cc: stable@dpdk.org. If it goes to stable, the fm10k hunk cannot be
taken as is: it drops the VF configure check and relies on the ethdev
VMDq validation, which stable does not have.

Info: failsafe.ini VMDq = P is not mentioned in the commit message.


Patch 6/8 drivers/net: fix reported RSS capability

Warning: Fixes: targets are in released versions but there is no
Cc: stable@dpdk.org.

Warning: xsc_np.c handles L3/L4 SRC_ONLY/DST_ONLY and LEVEL_INNERMOST,
but only IP|UDP|TCP are advertised, so ethdev rejects those bits in
configure and rss_hash_update. Advertise what the driver implements:

	info->flow_type_rss_offloads = RTE_ETH_RSS_IP |
		RTE_ETH_RSS_UDP | RTE_ETH_RSS_TCP |
		RTE_ETH_RSS_L3_SRC_ONLY | RTE_ETH_RSS_L3_DST_ONLY |
		RTE_ETH_RSS_L4_SRC_ONLY | RTE_ETH_RSS_L4_DST_ONLY |
		RTE_ETH_RSS_LEVEL_INNERMOST;

Info: idpf, cpfl and cpfl representor still report hash_key_size and
reta_size when rss_caps == 0. Move them under the same condition.


Patch 1/8 net/bnxt: remove leftover VMDq code in MAC helpers

Info: bnxt_mac_addr_add_op() still range-checks pool and indexes
bp->vnic_info[pool]. With ethdev forcing pool 0 when VMDq is not
configured, it can use vnic_info[0] like the remove path.