> On 3 Jun 2026, at 7:12 am, Luke Howard <[email protected]> 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
