On Wed, Jul 03, 2024 at 05:39:49AM +0200, Andrew Lunn wrote:

quoted

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/ (local)

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.