netdev - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241220121010.kkvmb2z2dooef5it@skbuf>
Date: Fri, 20 Dec 2024 14:10:10 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Luke Howard <lukeh@...l.com>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
	Kieran Tyrrell <kieran@...nda.com>,
	Max Hunter <max@...tershome.org>
Subject: Re: net: dsa: mv88e6xxx architecture

Hi Luke,

On Thu, Dec 19, 2024 at 08:02:38AM +1100, Luke Howard wrote:
> 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).

I think we need an AVB primer. What identifies an AVB stream? Should the
kernel have a database of them? What actions need to be taken for AVB
streams different than for best effort traffic? Is it about scheduling
priority, or about resource reservations, or? Does the custom behavior
pertain only to AVB streams or is it a more widely useful mechanism?

The tradition in Linux networking is to first create abstractions for
the software data path, and then to offload those abstractions to
capable accelerators. This allows certain platforms to do the task
more efficiently, but still using the same user visible API as what a
pure software implementation would require.

> 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.

What is the lifetime of an AVB packet in the Marvell DSA switches (in
enhanced AVB mode)? Where do they go from these global queues? Still to
the individual port TX queues, I assume? I find it a bit difficult to
understand the concept of global queues.

> This effectively imposes a mapping between TCs and AVB classes (with a
> third TC for non-AVB traffic).

I don't understand this. A mapping between which port's traffic classes
and the global AVB classes? You're saying that mqprio TCs 2 and 1 of all
ports are backed by the same queues?

> 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

I believe I don't understand enough of the Marvell AVB model to make any
comments yet.