netdev - Basic PCP/DEI-based queue classification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yv9VO1DYAxNduw6A@DEN-LT-70577>
Date:   Fri, 19 Aug 2022 09:09:38 +0000
From:   <Daniel.Machon@...rochip.com>
To:     <netdev@...r.kernel.org>
CC:     <kuba@...nel.org>, <vinicius.gomes@...el.com>,
        <vladimir.oltean@....com>, <thomas.petazzoni@...tlin.com>,
        <Allan.Nielsen@...rochip.com>, <maxime.chevallier@...tlin.com>,
        <nikolay@...dia.com>, <roopa@...dia.com>
Subject: Basic PCP/DEI-based queue classification

Hi netdev,

I am posting this thread in continuation of:

https://lore.kernel.org/netdev/20220415173718.494f5fdb@fedora/

and as a new starting point for further discussion of offloading PCP-based
queue classification into the classification tables of a switch.

Today, we use a proprietary tool to configure the internal switch tables for
PCP/DEI and DSCP based queue classification [1]. We are, however, looking for
an upstream solution.

More specifically we want an upstream solution which allows projects like DENT
and others with similar purpose to implement the ieee802-dot1q-bridge.yang [2].
As a first step we would like to focus on the priority maps of the "Priority
Code Point Decoding Table" and "Priority Code Point Enconding table" of the
802.1Q-2018 standard. These tables are well defined and maps well to the
hardware.

The purpose is not to create a new kernel interface which looks like what IEEE
defines - but rather to do the needed plumbing to allow user-space tools to
implement an interface like this.

In essence we need an upstream solution that initially supports:

 - Per-port mapping of PCP/DEI to QoS class. For both ingress and egress.

 - Per-port default priority for frames which are not VLAN tagged.

 - Per-port configuration of "trust" to signal if the VLAN-prio shall be used,
   or if port default priority shall be used.

In the old thread, Maxime has compiled a list of ways we can possibly offload
the queue classification. However none of them is a good match for our purpose,
for the following reasons:

 - tc-flower / tc-skbedit: The filter and action scheme maps poorly to hardware
   and would require one hardware-table entry per rule. Even less of a match
   when DEI is also considered. These tools are well suited for advanced
   classification, and not so much for basic per-port classification.

 - ip-link: The ingress and egress maps of ip-link is per-linux-vlan interface;
   we need per-port mapping. Not possible to map both PCP and DEI.

 - dcb-app: Not possible to map PCP/DEI (only DSCP).

We have been looking around the kernel to snoop what other switch driver
developers do, to configure basic per-port PCP/DEI based queue classification,
and have not been able to find anything useful, in the standard kernel
interfaces.  It seems like people use their own out-of-tree tools to configure
this (like mlnx_qos from Mellanox [3]).

Finally, we would appreciate any input to this, as we are looking for an
upstream solution that can be accepted by the community. Hopefully we can
arrive at some consensus on whether this is a feature that can be of general
use by developers, and furthermore, in which part of the kernel it should
reside:

 - ethtool: add new setting to configure the pcp tables (seems like a good
   candidate to us).

 - ip-link: add support for per-port-interface ingress and egress mapping of
   pcp/dei

 - dcb-*: as an extension or new command to the dcb utilities. The pcp tables
   seems to be in line with what dcb-app does with the application priority
   table.

 - somewhere else

In summary:

 - We would like feedback from the community on the suggested implemenation of
   the ieee-802.1Q Priority Code Point encoding an decoding tables.

 - And if we can agree that such a solution could and should be implemented;
   where should the implemenation go?

 - Also, should the solution be supported in the sw-bridge as well.

Thank you,
Best regards,

Daniel

[1] https://github.com/microchip-ung/qos-utils
[2] https://github.com/YangModels/yang/blob/main/standard/ieee/published/802.1/ieee802-dot1q-bridge.yang
[3] https://github.com/Mellanox/mlnx-tools/blob/master/ofed_scripts/utils/mlnx_qos