On 10/17/2026 12:44 AM, Stephen Hemminger wrote: > On Fri, 16 Oct 2026 15:05:46 +0200 > David Marchand <[email protected]> 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: [email protected]. 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: [email protected]. > > 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; >
Agreed, the advertised mask is incomplete. xsc_np.c does handle these RSS bits, but they are not reported in flow_type_rss_offloads. David, please fold this into the patch. Thanks, Wan Renyong
