Re: [PATCH net-next v2 5/6] net: dsa: mv88e6xxx: MQPRIO support

[Luke Howard <lukeh@padl.com>]

> On 3 Jun 2026, at 7:12 am, Luke Howard <lukeh@padl.com> wrote:
> 
>> In case of per port priority mapping, i don't know if this is working as
>> expected, as the IEEE priority mapping is done at ingress.
>> Eg. i think if MQPRIO channel mode is used to configure a pcp to queue mapping
>> on port 1 and a different mapping on port 2. Traffic received on port 1 that
>> gets forwarded to port 2 and egresses port 2 will end up in the queue
>> configured by the mapping on port 1. As mqprio is an egress qdisc, i don't
>> think that's expected.
> 
> Good point, it’s interesting there is egress mapping on the 6390 but only for FPri to DSCP. The Frame Priority Table set ordinal one would expect for egress QPri mapping is “reserved for future use”. (Be nice if it were an undocumented feature.)
> 
> I will remove the per-port mapping for the 6390 so all ports share the same mapping as they do on the 6352.

There is actually a slight impedance mismatch here which I hadn’t previously considered.

MQPRIO is a per-port Qdisc, but the FPri/QPri mappings on the switches are global (even, as you point out, on the 6390 as far as egress queues are concerned). Whilst we do validate that any MQPRIO-configured port has the same mapping, we can’t do anything about ports on which MQPRIO has not been configured (otherwise we would never be able to configure the first port). These ports implicitly inherit the per-switch mapping.

I think this is acceptable because, if one has not configured MQPRIO, one should have no expectation about which egress queue traffic ends up in. But there’s an alternative, more invasive, solution where the MQPRIO configuration is attached to the bridge itself, and is copied to (but not writable on) the user ports. This would require dsa_switch_ops changes.

Luke