Re: [PATCH net-next v2 5/6] net: dsa: mv88e6xxx: MQPRIO support
Luke Howard <[email protected]> Wed, 3 Jun 2026 11:40:35 +1000
| Newsgroups | dev.linux.lists.bridge,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.netdev |
|---|---|
| Message-ID | <[email protected]> |
> 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.