On 3 Jun 2026, at 10:15 am, Luke Howard [off-list ref] wrote:

quoted

On 3 Jun 2026, at 9:55 am, Andrew Lunn [off-list ref] wrote:

quoted

But there’s an alternative, more invasive, solution where the MQPRIO
configuration is attached to the bridge itself.

What about ports which are not attached to a bridge? They are just
standalone, have an IP address of their own, etc.

That is a good point. So, barring a switch feature I’ve not yet found, I think the only options are either to drop MQPRIO offload, or to accept that ports with no MQPRIO mapping inherit the per-switch mapping. Arguably that’s the case today anyway (each chip has its own default frame priority to queue mapping), so the user should have no expectation of queue assignment on a port that hasn’t been configured.

We could add (e.g.) bridge_setup_tc to dsa_switch_ops, which (in the mv88e6xxx implementation) could validate the bridge contained all user ports. But it would not be possible to block a port from leaving as port_bridge_leave cannot return an error, and tearing MQPRIO config down silently would be a different sort of bad.