> On 3 Jun 2026, at 10:15 am, Luke Howard <[email protected]> wrote: > >> On 3 Jun 2026, at 9:55 am, Andrew Lunn <[email protected]> wrote: >> >>> 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.
