> On 3 Jun 2026, at 12:41 pm, Andrew Lunn <[email protected]> wrote:
>
>> 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.
>
> There can be multiple bridges, even as far as one bridge per port.
Right, per the above mv88e6xxx would return -EOPNOTSUPP if the bridge did not
contain all DSA user ports. But without a means to block the removal of ports
from bridges it would not be possible to maintain this invariant.
> For switch wide properties, you basically have to allow the first user
> to configure it, refcount additional users get added and removed, and
> only allow the last user to change it.
Indeed, that’s what this series does. But it comes with the discussed caveat
that ports without MQPRIO (whether or not they are part of a bridge) implicitly
inherit the global FPri to QPri mapping. I think that is acceptable given that
users should have no expectaitons about the default mapping, but others may
disagree.
> The alternative is return -EOPNOTSUPP, and let the kernel do it in
> software, if a user wants something different to the global
> setting. The hardware is only there to accelerate what Linux can
> already do in software. That is the model we use.
Yes, this is how it is implemented.
Luke
