Re: [PATCH net-next v2 5/6] net: dsa: mv88e6xxx: MQPRIO support
O Thu, Jun 04, 2026 at 07:36:07AM +1000, Luke Howard wrote: > I realise I misunderstood you: this is about exposing the 6390’s egress FPri > to PCP mapping via DSA/DCB rewrite? That’s really cool, and orthogonal to > MQPRIO; apologies for my confusion. No, it's about configuring the ingress pcp to QPri mappings. The patch has been submitted to the mailing list: https://lore.kernel.org/netdev/20260604-net-next-mv88e6xxx-pcp-prio-v1-0-f9d10fe6c...@luminex.be/ Cedric
Re: [PATCH net-next v2 5/6] net: dsa: mv88e6xxx: MQPRIO support
> 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. It appears out one can set the egress QPri with a TCAM entry. So we may be able to correctly implement MQPRIO with an entry that matches on the PCP and sets the QPri and DPV bits. We’d need to be careful that the flower API couldn’t remove one of these entries. Luke
Re: [PATCH net-next v2 5/6] net: dsa: mv88e6xxx: MQPRIO support
> On 3 Jun 2026, at 12:41 pm, Andrew Lunn 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
Re: [PATCH net-next v2 5/6] net: dsa: mv88e6xxx: MQPRIO support
>> 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 misread the data sheet. Egress PCP to FPRI mapping is possible per-port on > the 6390 family. This doesn’t resolve the other issue (MQPRIO-less ports on > the 6352 family). But it is good news and I will revise accordingly in the > next patch revision. I did not misread the data sheet. The 6390 family does not support egress FPri to QPri mapping. It supports egress FPri to _PCP_ mapping (i.e. the internal and wire representations of the priority can differ). Clearly needed a third coffee. Luke
Re: [PATCH net-next v2 5/6] net: dsa: mv88e6xxx: MQPRIO support
> 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. 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. 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. Andrew
Re: [PATCH net-next v2 5/6] net: dsa: mv88e6xxx: MQPRIO support
> On 3 Jun 2026, at 7:12 am, Luke Howard 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 misread the data sheet. Egress PCP to FPRI mapping is possible per-port on the 6390 family. This doesn’t resolve the other issue (MQPRIO-less ports on the 6352 family). But it is good news and I will revise accordingly in the next patch revision.
Re: [PATCH net-next v2 5/6] net: dsa: mv88e6xxx: MQPRIO support
> On 3 Jun 2026, at 10:15 am, Luke Howard wrote: > >> On 3 Jun 2026, at 9:55 am, Andrew Lunn 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.
Re: [PATCH net-next v2 5/6] net: dsa: mv88e6xxx: MQPRIO support
> On 3 Jun 2026, at 9:55 am, Andrew Lunn 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. Luke
Re: [PATCH net-next v2 5/6] net: dsa: mv88e6xxx: MQPRIO support
> 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. Andrew
Re: [PATCH net-next v2 5/6] net: dsa: mv88e6xxx: MQPRIO support
> On 3 Jun 2026, at 7:12 am, Luke Howard 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
Re: [PATCH net-next v2 5/6] net: dsa: mv88e6xxx: MQPRIO support
> 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. > I have a patch that hasn't been submitted to the mailing list yet which > implements support for the dcb app pcp-prio command. This is also done by > configuring the IEEE priority mapping table. Definitely happy to take a look if and when you submit, but I do plan to continue with this patch series (originally proposed as an RFC in September 2025). Cheers, Luke
Re: [PATCH net-next v2 5/6] net: dsa: mv88e6xxx: MQPRIO support
On Tue, Jun 02, 2026 at 10:43:50AM +1000, Luke Howard wrote:
> +static int mv88e6xxx_setup_tc_mqprio(struct dsa_switch *ds, int port,
> + struct tc_mqprio_qopt_offload *mqprio)
> +{
> + struct netlink_ext_ack *extack = mqprio->extack;
> + u8 ieee_pri_map[IEEE_8021Q_MAX_PRIORITIES];
> + struct mv88e6xxx_chip *chip = ds->priv;
> + struct mv88e6xxx_tc_policy *pol;
> + enum mv88e6xxx_tc_mode tc_mode;
> + struct net_device *user;
> + bool can_update_pol;
> + bool per_port_pol;
> + int num_tc, err;
> +
> + if (!dsa_is_user_port(ds, port))
> + return -EINVAL;
> +
> + num_tc = mv88e6xxx_validate_tc_mqprio(chip, mqprio, &tc_mode,
> ieee_pri_map);
> + if (num_tc < 0)
> + return num_tc;
> +
> + user = dsa_to_port(ds, port)->user;
> +
> + per_port_pol = (tc_mode == MV88E6XXX_TC_MODE_QPRI &&
> + chip->info->ops->port_ieee_pri_map);
> +
> + mv88e6xxx_reg_lock(chip);
> +
> + pol = &chip->tc_policy;
> +
> + if (num_tc && pol->tc_mode && pol->tc_mode != tc_mode) {
> + NL_SET_ERR_MSG_MOD(extack, "all switch ports must use the same
> MQPRIO mode");
> + err = -EOPNOTSUPP;
> + goto err_unlock;
> + }
> +
> + can_update_pol = per_port_pol ||
> + !pol->tc_port_mask || pol->tc_port_mask == BIT(port);
> + if (!can_update_pol && num_tc &&
> + !mv88e6xxx_tc_mode_map_equal(chip, tc_mode, ieee_pri_map)) {
> + NL_SET_ERR_MSG_MOD(extack, "only a single priority mapping
> supported per switch");
> + err = -EOPNOTSUPP;
> + goto err_unlock;
> + }
> +
> + err = mv88e6xxx_mqprio_netdev_set_tc(user, &mqprio->qopt, num_tc);
> + if (err)
> + goto err_reset_tc;
> +
> + if (can_update_pol) {
> + const u8 *map = num_tc ? ieee_pri_map : NULL;
> +
> + if (per_port_pol)
> + err = mv88e6xxx_set_port_ieee_pri_map(chip, port, map);
> + else
> + err = mv88e6xxx_set_ieee_pri_map(chip, map);
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.
I have a patch that hasn't been submitted to the mailing list yet which
implements support for the dcb app pcp-prio command. This is also done by
configuring the IEEE priority mapping table.
Cedric
