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.