Re: [PATCH net-next v4 1/3] net: stmmac: set real_num_tx_queues to max(offset + count)

[netdev-bot+sashiko@kernel.org]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The commit message describes only one of two failure modes.

--

net: stmmac: set real_num_tx_queues to max(offset + count)

This patch changes how tc_setup_dwmac510_mqprio() computes the number of
real TX queues. It now uses the maximum of offset[i] + count[i] instead
of the sum of the per-TC counts. As a result, real_num_tx_queues covers
the highest queue in the TC map even when the mqprio layout has gaps or
a non-zero first offset.

> netif_set_real_num_tx_queues() then passes this too-small count to
> netif_setup_tc(), which invalidates the mapping.

[Severity: Low]
Is this description complete? It seems to cover only layouts where TC0
itself ends up out of range.

In tc_setup_dwmac510_mqprio(), stmmac_set_ndev_tcs() runs before
netif_set_real_num_tx_queues(). It starts by calling netdev_reset_tc(),
which zeroes dev->prio_tc_map:

drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c:stmmac_set_ndev_tcs() {
	...
	netdev_reset_tc(ndev);
	...
}

So when netif_setup_tc() runs, every priority maps to TC0, and the TC0
check is the only one that can fire:

net/core/dev.c:netif_setup_tc() {
	...
	/* If TC0 is invalidated disable TC mapping */
	if (res.offset + res.count > txq) {
		netdev_warn(dev, "Number of in use tx queues changed invalidating tc mappings. Priority traffic classification disabled!\n");
		WRITE_ONCE(dev->num_tc, 0);
		return;
	}
	...
}

mqprio_init() installs the user's prio_tc_map only after the offload
callback returns.

Take a gapped layout where TC0 fits, such as "queues 1@0 1@2". The old
sum gives real_num_tx_queues = 2, and nothing gets invalidated. TC1
keeps offset 2, so on transmit:

netdev_core_pick_tx()
  netdev_pick_tx()
    skb_tx_hash()          /* returns 2 */
  netdev_cap_txqueue()     /* 2 >= real_num_tx_queues, warns, returns 0 */

stmmac does not implement ndo_select_queue. That traffic class,
including express or preemptible FPE traffic, would therefore go out on
queue 0 with only a ratelimited warning. Its mapping would not be
rejected.

The code change handles both cases. Could the commit message also
describe this misrouting case, so backporters can see the full impact of
the bug being fixed?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261001-stmmac-mqprio-prio-offload-v4-0-a74610d7f1e5%40oss.qualcomm.com