netdev - net: dsa: mv88e6xxx architecture

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: <B50BFF9A-DD1D-45AC-80BF-62325C939533@padl.com>
Date: Thu, 19 Dec 2024 08:02:38 +1100
From: Luke Howard <lukeh@...l.com>
To: netdev@...r.kernel.org
Cc: Vladimir Oltean <olteanv@...il.com>, Andrew Lunn <andrew@...n.ch>,
        Kieran Tyrrell <kieran@...nda.com>, Max Hunter <max@...tershome.org>
Subject: net: dsa: mv88e6xxx architecture

I am working on TC support for the mv88e6xxx DSA driver. [1]

Two architectural questions.

mv88e6xxx switches support AVB admission control, where frames with AVB frame priorities are discarded unless their ATU entry has a flag indicating they belong to an AVB stream. This requires knowing the intent behind fdb_add() or mdb_add(). One, intrusive, option would be a NTF_EXT flag that could be set by the SRP [2] daemon. My current approach is a NET_DSA_MV88E6XXX_AVB Kconfig option which assumes all static FDB/MDB updates on MQPRIO-enabled ports should have the AVB flag set. MQPRIO and CBS are supported without this option, but will fail AVB/TSN switch certification (which floods the switch with “AVB” frames not setup by SRP).

The second question is whether Linux TCs should be mapped to AVB classes or to queues. The admission control described above requires dedicated, global queues for Class A and B AVB traffic. This effectively imposes a mapping between TCs and AVB classes (with a third TC for non-AVB traffic). On mv88e6xxx chips with more than 4 TX queues, a mapping between TCs and TX queues would provide more flexibility, particularly as it would also allow per-port MQPRIO policies (a feature not available on the 6352 family).

I think I have made the right set of tradeoffs but clearly there is compromise between supporting CBS generally, and supporting AVB/TSN properly. Any thoughts would be appreciated. More detail can be found in the avb.h comment in [1].

[1] https://github.com/PADL/linux/compare/158f238aa69d91ad74e535c73f552bd4b025109c...PADL:linux:marvell-fqtss?expand=1
[2] 802.1Q Clause 35, also our open source implementation at https://github.com/PADL/SwiftMRP