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: <5bdb17e0-cd7a-44e3-bdd4-d0686ea61b14@lunn.ch>
Date: Sat, 21 Dec 2024 22:36:22 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Luke Howard <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 09:52:27AM +1100, Luke Howard wrote:
>     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?
> 
> 
> One could:
> 
> * Add (e.g.) TCA_MQPRIO_TC_ENTRY_SRP to indicate the TC is associated with a
> SRP class
> * Add (e.g.) NTF_EXT_SRP_MANAGED to indicate the FDB/MDB entry was inserted by
> the SRP daemon

Doesn't FDB/MDB imply you have a bridge? What about an isolated port
which is not a member of a bridge, there is only local traffic?

> Packets with TCs marked TCA_MQPRIO_TC_ENTRY_SRP to DAs not marked
> NTF_EXT_SRP_MANAGED would be dropped (or deprioritised).
> 
> For mv88e6xxx, TCA_MQPRIO_TC_ENTRY_SRP would be supported for “AVB” traffic
> classes, and NTF_EXT_SRP_MANAGED would map to MV88E6XXX_G1_ATU_DATA_STATE_
> {UC,MC}_STATIC_AVB_NRL.
> 
> Or, we do nothing. As far as I can tell the biggest issue with not supporting
> this is whether the bridge would pass the Avnu test suite. That’s not so
> important to me, but it might be to some other users.

It is back to, we use the hardware to accelerate what Linux can
already do in software. If you only use the switch ports in isolated
mode, no bridge, you could probably get away with not supporting AVB
on the linux bridge. But if you need the software bridge to setup the
acceleration via a hardware bridge, you will need the software bridge
to work with AVB without acceleration.

	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ