Re: [PATCH net-next v1 0/8] net: dsa: realtek: rtl8365mb: DCB ingress QoS offload

[Linus Walleij]

Hi Oleksij,

thanks for your patch!

On Fri, Oct 2, 2026 at 1:58 PM Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> wrote:

> Add DCB-based ingress QoS offload for the RTL8365MB switch via the dcbnl
> app interface: a per-port default priority, PCP trust, and DSCP trust.
> It also adds the few net/core ieee8021q helpers the driver needs.
>
> Nothing changes on the wire until an admin enables PCP or DSCP trust;
> until then every frame takes the port default and lands on one queue.
>
> Tested on an RTL8365MB-VC.
>
> ETS scheduling and CPU-tag ingress pre-classification build on this and
> will follow once it lands.
>
> Oleksij Rempel (8):
>   net: ieee8021q: print traffic type and queue count with %u
>   net: ieee8021q: add pcp_to_tt()
>   net: ieee8021q: clarify the tt_to_tc() traffic-class mapping
>   net: ieee8021q: add tt_to_pcp()
>   net: dsa: realtek: rtl8365mb: store the egress queue count per chip
>   net: dsa: realtek: rtl8365mb: add QoS baseline and DCB default
>     priority
>   net: dsa: realtek: rtl8365mb: offload DCB apptrust
>   net: dsa: realtek: rtl8365mb: offload DCB DSCP-to-priority

I have one major feedback on the series and it's pretty predictable:
the RTL8366RB has most of these features as well, so they
need to be added to the common helpers in rtl83xx.c and
realtek.h.

- RTL8366RB has the same type of traffic policy, albeit
  with 6 queues per port rather than 8.

- Logic traffic queues are slightly different, RB uses
  queues 0 & 5 for two queues, 0, 1 & 5 for three
  and so on.

- The DSCP bits have slightly different bit layout so each
  backend must deal with this.

- The apptrust in the RTL8366RB is *global* rather than
  per-port so this could perhaps be handled in each back-end.
  The global setting will even affect the CPU port.

If you add something like this to the realtek_ops in
realtek.h:

int (*qos_get_port_prio)(struct realtek_priv *priv, int port);
int (*qos_set_port_prio)(struct realtek_priv *priv, int port,  u8 iprio);

int (*qos_set_pcp_prio)(struct realtek_priv *priv, u8 pcp, u8 iprio);

int (*qos_get_dscp_prio)(struct realtek_priv *priv, u8 dscp);
int (*qos_set_dscp_prio)(struct realtek_priv *priv, u8 dscp, u8 iprio);

int (*qos_set_port_num_queues)(struct realtek_priv *priv, int port,
unsigned int num_queues);
int (*qos_set_prio_tc)(struct realtek_priv *priv,
unsigned int num_queues, u8 iprio, u8 tc);

The getters would return an internal priority or a negative error.
Queue callbacks would own register encoding, table selection
and logical-TC-to-hardware-QID translation.

Common code (rtl83xx.c) could then provide:

- Default-priority get/set callbacks, including PCP <->  traffic-type
  conversion.
- DSCP get/add/delete callbacks, including the series replacement
  guard and restoration of the IETF default.
- Initialization of all eight PCP mappings and all 64 DSCP mappings.
- Priority-to-traffic-class initialization using ieee8021q_tt_to_tc().
- Per-port Best Effort initialization.

Both chip setups should expose their queue count through the
existing ds->num_tx_queues, and set ds->dscp_prio_mapping_is_global
when registering DSCP offload. There is no need to duplicate those
properties in another common structure.

Does this make sense?

Yours,
Linus Walleij