This patch series adds support for dcb pcp app to the mv88e6xxx
driver. The pcp app is there to configure pcp based queue
classification.

In the Marvell switches this is done by configuring the IEEE PRI Mapping
table. There are different hardware implementations of this table
depending on the switch:
* a global table
* the 6390 has one table per port
* the 6393 has one table for DEI=0, and another table for DEI=1 per port

For this the DSA framework needs to be extended. The implementation for
pcp-prio in the DSA framework is very similar to existing dcsp-prio
implementation.

There's another patch series [1] on the mailing list that uses the same
IEEE PRI Mapping table to implement MPQRIO. To me the dcb pcp app feels
like the natural way to configure the pcp to QPri mappings in the
switch.

[1] https://lore.kernel.org/netdev/20260602-mv88e6xxx-8021qat-mqprio-v2-0-72be14522e7c@padl.com/

Signed-off-by: Cedric Jehasse <cedric.jehasse@luminex.be>
---
Cedric Jehasse (2):
      net: dsa: add support for dcb pcp app
      net: dsa: mv88e6xxx: add support for dcb pcp app

 drivers/net/dsa/mv88e6xxx/Makefile |   1 +
 drivers/net/dsa/mv88e6xxx/chip.c   |  36 ++++++
 drivers/net/dsa/mv88e6xxx/chip.h   |  17 +++
 drivers/net/dsa/mv88e6xxx/dcb.c    | 229 +++++++++++++++++++++++++++++++++++++
 drivers/net/dsa/mv88e6xxx/dcb.h    |  21 ++++
 drivers/net/dsa/mv88e6xxx/port.c   |  28 ++++-
 drivers/net/dsa/mv88e6xxx/port.h   |   8 ++
 include/net/dsa.h                  |  10 ++
 net/dsa/user.c                     | 126 ++++++++++++++++++--
 9 files changed, 467 insertions(+), 9 deletions(-)
---
base-commit: 09942ddedcb960f9e78fd817ec33f501d1040c5b
change-id: 20260603-net-next-mv88e6xxx-pcp-prio-5752caa7926b
prerequisite-change-id: 20260430-net-next-mv88e6xxx-cbs-2121169caa68:v5
prerequisite-patch-id: 8ad59c43368d4639e0cabcc59a7f6e487560d3f7
prerequisite-patch-id: 88ee88bf34ac3631056bc92c6c6251c29cf7223c

Best regards,
-- 
Cedric Jehasse <cedric.jehasse@luminex.be>

> On 4 Jun 2026, at 6:30 pm, Cedric Jehasse via B4 Relay <devnull+cedric.jehasse.luminex.be@kernel.org> wrote:
> 
> To me the dcb pcp app feels like the natural way to configure the pcp to QPri mappings in the switch.

Revisiting this, I think the DCB PCP to PRIO mapping should instead configure the Port IEEE Priority Remapping registers (6352) or Ingress PCP mapping (6390). There’s nothing in dcb-app(8) that suggests to me that PRIO implies queue just because the PCP selector was used.

This is a bit unfortunate as configuring the PCP to QPri would be useful. But we could get the same end result by mapping to FPri and accepting the default FPri/QPri mapping.

(The 6352 data sheet is confusing when it refers to the IEEE-PRI register setting the “frame’s priority”, but the width of the field implies it is indeed QPri.)

I do (now) agree that MQPRIO is not the place to configure this.

Luke

> On 4 Jun 2026, at 6:30 pm, Cedric Jehasse via B4 Relay <devnull+cedric.jehasse.luminex.be@kernel.org> wrote:
> 
> This patch series adds support for dcb pcp app to the mv88e6xxx
> driver. The pcp app is there to configure pcp based queue
> classification.

Somehow these patches didn’t arrive in my inbox, but (looking on lore) they all LGTM.

The only comments I had:

- whether you might use IEEE_8021Q_MAX_PRIORITIES instead of 8 (this requires importing dcbnl.h though)
- the user might infer the ‘prio’ parameter name means we are remapping frame priorities rather than assigning to a queue. Perhaps it could have a different name?

Luke

> On 4 Jun 2026, at 6:30 pm, Cedric Jehasse via B4 Relay <devnull+cedric.jehasse.luminex.be@kernel.org> wrote:
> 
> There's another patch series [1] on the mailing list that uses the same
> IEEE PRI Mapping table to implement MPQRIO. To me the dcb pcp app feels
> like the natural way to configure the pcp to QPri mappings in the
> switch

I’m not familiar with the API or user tools, but the fact it supports both global and ingress mappings makes it seem like a better option, agreed.

It seems like we maybe could support MQPRIO properly with TCAM but perhaps that isn’t really necessary (certainly not for my all-ports-in-bridge use case, where there isn’t a distinction between ingress and egress priority mappings).

I still need to find a similarly natural way to expose the switch’s AVB capabilities / 802.1Qat admission control. Perhaps there is none and it will need to remain a local patch.

On Thu, Jun 04, 2026 at 08:37:17PM +1000, Luke Howard wrote:
> I still need to find a similarly natural way to expose the switch’s AVB capabilities / 802.1Qat admission control. Perhaps there is none and it will need to remain a local patch.

There's a devlink port param command. I've been wondering if this could be used
to set a port's AvbMode. However:
* at the moment there are no drivers supporting this.
  eg. devlink_nl_port_param_set_doit and other return this isn't supported
* i don't know if AvbMode is a valid use for devlink port param, and if it
  would get accepted

Cedric

Hi Cedric,

> On 4 Jun 2026, at 10:01 pm, Cedric Jehasse <cedric.jehasse@gmail.com> wrote:
> 
> On Thu, Jun 04, 2026 at 08:37:17PM +1000, Luke Howard wrote:
>> I still need to find a similarly natural way to expose the switch’s AVB capabilities / 802.1Qat admission control. Perhaps there is none and it will need to remain a local patch.
> 
> There's a devlink port param command. I've been wondering if this could be used
> to set a port's AvbMode. However:
> * at the moment there are no drivers supporting this.
>  eg. devlink_nl_port_param_set_doit and other return this isn't supported
> * i don't know if AvbMode is a valid use for devlink port param, and if it
>  would get accepted

mv88e6xxx already exposes the ATU_hash driver-specific devlink parameter, so there is a precedent which augurs well.

A per-port AVB mode devlink could configure:

- AVB mode to enhanced
- iso ptrs to number of enabled ports * N (currently we use N=64)
- enabling interpreting AVB_NRL entries as AVB with G1_ATU_CTL_MAC_AVB

The leaves two issues:

- if at least one port has AVB mode set, we could install permanent MDB entries as AVB_NRL. But here we have the old problem, that AVB mode is on the ingress port, whereas MDB entries are on the egress port.
- also the AVB FPri and QPri values would need to be configured, either via another devlink parameter or MQPRIO

This approach would integrate well with your CBS and DCB patches. Having said that, AVB mode could likely be reimplemented with TCAM, and (assuming an SRP daemon that knew how to install those flower entries) that might be a more portable and idiomatic solution. I am not sure how it would perform compared to the native AVB admission control in the switch.

Luke

On Fri, Jun 05, 2026 at 08:51:56AM +1000, Luke Howard wrote:
> Hi Cedric,
> 
> > On 4 Jun 2026, at 10:01 pm, Cedric Jehasse <cedric.jehasse@gmail.com> wrote:
> > 
> > On Thu, Jun 04, 2026 at 08:37:17PM +1000, Luke Howard wrote:
> >> I still need to find a similarly natural way to expose the switch’s AVB capabilities / 802.1Qat admission control. Perhaps there is none and it will need to remain a local patch.
> > 
> > There's a devlink port param command. I've been wondering if this could be used
> > to set a port's AvbMode. However:
> > * at the moment there are no drivers supporting this.
> >  eg. devlink_nl_port_param_set_doit and other return this isn't supported
> > * i don't know if AvbMode is a valid use for devlink port param, and if it
> >  would get accepted
> 
> mv88e6xxx already exposes the ATU_hash driver-specific devlink parameter, so there is a precedent which augurs well.
> 
> A per-port AVB mode devlink could configure:
> 
> - AVB mode to enhanced
> - iso ptrs to number of enabled ports * N (currently we use N=64)
> - enabling interpreting AVB_NRL entries as AVB with G1_ATU_CTL_MAC_AVB

I don't know enough about AVB, so this might not apply here....

What does the pure software version of AVB look like? Is there a need
to configure these parameters? If not, why not? If there is, what API
is currently used?

Ideally, the user should not need to know if some functionality has
been accelerated by offloading it to hardware. They just configure it
using the standard Linux model of the feature.

	Andrew

Hi Andrew,

> I don't know enough about AVB, so this might not apply here....
> 
> What does the pure software version of AVB look like? Is there a need
> to configure these parameters? If not, why not? If there is, what API
> is currently used?

Qdisc configuration for AVB is described here [1] albeit with reversed numbering of TCs. CBS parameters are usually managed dynamically by SRP (in user space), but static configuration as shown in the link would be common for automative AVB/TSN.

> Ideally, the user should not need to know if some functionality has
> been accelerated by offloading it to hardware. They just configure it
> using the standard Linux model of the feature.

Absolutely, and that was the model I used when building a SRP daemon, which I first tested with the software bridge and some i210s.

One issue is that AVB is typically configured using MQPRIO, which configures egress queue mapping. The Marvell switches support ingress queue mapping (the subject of this patch), although there is a special case for AVB traffic which does allow for egress queue mapping.

The main issue is that inbound frames belonging to AVB TCs that do _not_ have a SRP-managed DA must be dropped. This permits those queues’ CBS bandwidth to be reserved for AVB streams.Marvell implements this with the STATIC_AVB_NRL entry state, combined with an ingress port flag that enables the packet filtering.

My patch mapped the Marvell model to the software bridge, i.e. new IFLA_BRPORT and MDB flags. However, Nikolay (correctly) points out that these are unidiomatic for Linux.

My understanding is that these should likely be managed with tc-flower. The SRP daemon would manage tc-flower entries along with the MDB when an AVB stream is admitted. Unfortunately, implemetning this in mv88e6xxx would be more complicated: it would either require intercepting the tc-flower requests and mapping them to native AVB admission control (which may be fragile), or adding PCP/DA matching to the TCAM implementation (which may not be sufficiently performant, more research is needed).

Luke

[1] https://tsn.readthedocs.io/avb.html

> On 5 Jun 2026, at 11:13 am, Luke Howard <lukeh@padl.com> wrote:
> 
>> Ideally, the user should not need to know if some functionality has
>> been accelerated by offloading it to hardware. They just configure it
>> using the standard Linux model of the feature.
> 
> Absolutely, and that was the model I used when building a SRP daemon, which I first tested with the software bridge and some i210s.

Which does beg the question why I hadn’t considered the admission control issue when originally implementing against the software bridge. That’s my bad, and perhaps had I discovered tc-flower earlier I would have a different mental model of how to map this to mv88e6xxx.

Also whilst the admission control is necessary to correctly implement 802.1Qat and pass the Avnu test suites, it might not matter for many networks.

I will think about how to implement these semantics with tc-flower/TCAM, likely after I take a look at submitting your DSA in-band/Marvell RMU patches.

Luke