Re: net: dsa: mv88e6xxx architecture

[Andrew Lunn <andrew@lunn.ch>]

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