linux-kernel - Re: net: dsa: Realtek switch drivers

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: <20240708141400.xbuor67hnnkxyigh@skbuf>
Date: Mon, 8 Jul 2024 17:14:00 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Chris Packham <chris.packham@...iedtelesis.co.nz>
Cc: Andrew Lunn <andrew@...n.ch>,
	Luiz Angelo Daros de Luca <luizluca@...il.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	"alsi@...g-olufsen.dk" <alsi@...g-olufsen.dk>,
	Florian Fainelli <f.fainelli@...il.com>,
	Marek Behún <kabel@...nel.org>,
	"ericwouds@...il.com" <ericwouds@...il.com>,
	David Miller <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>,
	Paolo Abeni <pabeni@...hat.com>,
	"justinstitt@...gle.com" <justinstitt@...gle.com>,
	"rmk+kernel@...linux.org.uk" <rmk+kernel@...linux.org.uk>,
	netdev <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"sander@...nheule.net" <sander@...nheule.net>
Subject: Re: net: dsa: Realtek switch drivers

On Wed, Jul 03, 2024 at 05:39:49AM +0200, Andrew Lunn wrote:
> > One reason for using DSAI've just found is that in theory the RTL930x
> > supports a CPU disabled mode where you do connect it to an external CPU and
> > the data travels over SGMII like you'd get with a traditional DSA design.
> > It's not a mode I'm planning on supporting anytime soon but it might come up
> > when I get round to submitting some patches.
> 
> You might want to look at ocelot, which is both a pure switchdev and a
> DSA driver. Its design is not great because it became dual later in
> its life. I suspect it would be designed differently if this has been
> considered at the beginning.
> 
> 	   Andrew

Another thing to consider is that you might want to join efforts with
Bootlin who had a similar (and still unresolved) issue with ipqess/qca8k.
See some of the feedback that they received.
https://lore.kernel.org/netdev/20231116215645.3ex4yp36hrrm4uti@skbuf/

In short, I am in principle in favor of extracting core stuff out of
DSA into a more generic 'eth switch' library which is frontend-agnostic
(this is also what the TODO in Documentation/networking/dsa/dsa.rst is
really about, despite not being very well described). That new framework
would essentially be the things that DSA does well, except for tagging
packets, handling the conduit interface, etc. I just don't have the time
(or incentive, sadly) to do it.

The most advanced switchdev drivers like mlxsw will probably not benefit
from it, because they have their own highly specific use cases, although
most of the rest should, since there is a lot of boilerplate which could
go to common code, and which nobody really likes to re-re-re-write or
re-re-re-review.