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-next>] [day] [month] [year] [list]

Message-ID: <fbbd0f33-240f-41c7-bb5f-3cea822c4bf9@lunn.ch>
Date: Fri, 20 Dec 2024 23:33:05 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Luke Howard Bentata <lukeh@...l.com>
Cc: Vladimir Oltean <olteanv@...il.com>, netdev@...r.kernel.org,
	Kieran Tyrrell <kieran@...nda.com>,
	Max Hunter <max@...tershome.org>
Subject: Re: net: dsa: mv88e6xxx architecture

On Sat, Dec 21, 2024 at 08:43:50AM +1100, Luke Howard Bentata wrote:
> Hi Vladimir,
> 
> 
>     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?
> 
> 
> AVB is an umbrella term which encompasses 802.1AS (gPTP), 802.1Qav (CBS),
> 802.1Qat (SRP), and various application layer protocols. This patch series is
> concerned with CBS and, tangentially, SRP: the existing mv88e6xxx PTP support
> sufficies for 802.1AS, and the application layer protocols are of no concern to
> the kernel. Further, the existing TC abstractions for CBS also suffice, and the
> patch series simply implements those.
> 
> Your question: what is an AVB stream, and what (if any) state needs to be
> maintained in the kernel?
> 
> Stream reservations, between “talkers” (sources) and “listeners” (sinks) are
> coordinated by the Multiple Stream Reservation Protocol (MSRP). (Confusingly,
> _SRP_ itself is an umbrella term encompassing MVRP, MMRP and MSRP. The existing
> MVRP support in the kernel only implements part of the MRP state machine.)
> 
> MSRP coordinates talker advertisements (consisting of a 64-bit stream ID, a
> [typically multicast] DA, VID, bandwidth requirement, and PCP) with listener
> advertisements. It also coordinates “domain” advertisements which establish a
> mapping between AVB or SRP “classes”, and a (PCP, VID) tuple.
> 
> At a high level, the kernel does not need to know anything about SRP: it can,
> and IMO should (like the PTP state machine) be implemented completely in user
> space. Once SRP has established there is sufficient bandwidth and latency for a
> steam to flow, it adds the stream DA to the FDB or MDB, and configures the CBS
> policy appropriately on the egress port.
> 
> The catch is what to do with frames that share a priority with an AVB class but
> are not negotiated by SRP. These frames could crowd out frames from AVB
> streams. Marvell’s solution is a flag in the ATU which indicates that the DA
> was added by SRP. This is the one case where a new kernel interface
> (specifically, a flag passed down to {fdb,mdb}_add()), could be useful.

For a moment, forget about Marvell. Think about a purely software
solution, maybe using the Linux bridge, and a collection of e1000e
cards. Does the same problem exist? How would you solve it?

First solve the generic software case first, and then offload it to
the hardware.

	Andrew