2019-06-21 15:39:54

by Claudiu Manoil

[permalink] [raw]
Subject: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node

Add the switch device node, available on PF5, so that the
switch port sub-nodes (net devices) can be linked to
corresponding board specific phy nodes (external ports) or
have their link mode defined (internal ports).
The switch device features 6 ports, 4 with external links
and 2 internally facing to the ls1028a SoC and connected via
fixed links to 2 internal enetc ethernet controller ports.
Add the corresponding enetc internal port device nodes,
mapped to PF2 and PF6 PCIe functions.
And don't forget to enable the 4MB BAR4 in the root complex
ECAM space, where the switch registers are mapped.

Signed-off-by: Claudiu Manoil <[email protected]>
---
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 58 ++++++++++++++++++-
1 file changed, 57 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 4cdf84c63320..2462dd936212 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -421,7 +421,9 @@
/* PF1: VF0-1 BAR0 - non-prefetchable memory */
0x82000000 0x0 0x00000000 0x1 0xf8210000 0x0 0x020000
/* PF1: VF0-1 BAR2 - prefetchable memory */
- 0xc2000000 0x0 0x00000000 0x1 0xf8230000 0x0 0x020000>;
+ 0xc2000000 0x0 0x00000000 0x1 0xf8230000 0x0 0x020000
+ /* BAR4 (PF5) - non-prefetchable memory */
+ 0x82000000 0x0 0x00000000 0x1 0xfc000000 0x0 0x400000>;

enetc_port0: ethernet@0,0 {
compatible = "fsl,enetc";
@@ -431,12 +433,66 @@
compatible = "fsl,enetc";
reg = <0x000100 0 0 0 0>;
};
+ ethernet@0,2 {
+ compatible = "fsl,enetc";
+ reg = <0x000200 0 0 0 0>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
ethernet@0,4 {
compatible = "fsl,enetc-ptp";
reg = <0x000400 0 0 0 0>;
clocks = <&clockgen 4 0>;
little-endian;
};
+ switch@0,5 {
+ compatible = "mscc,felix-switch";
+ reg = <0x000500 0 0 0 0>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* external ports */
+ switch_port0: port@0 {
+ reg = <0>;
+ };
+ switch_port1: port@1 {
+ reg = <1>;
+ };
+ switch_port2: port@2 {
+ reg = <2>;
+ };
+ switch_port3: port@3 {
+ reg = <3>;
+ };
+ /* internal to-cpu ports */
+ port@4 {
+ reg = <4>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ port@5 {
+ reg = <5>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
+ ethernet@0,6 {
+ compatible = "fsl,enetc";
+ reg = <0x000600 0 0 0 0>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
};
};
};
--
2.17.1


2019-06-21 16:50:14

by Andrew Lunn

[permalink] [raw]
Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node

On Fri, Jun 21, 2019 at 06:38:50PM +0300, Claudiu Manoil wrote:
> The switch device features 6 ports, 4 with external links
> and 2 internally facing to the ls1028a SoC and connected via
> fixed links to 2 internal enetc ethernet controller ports.

Hi Claudiu

> + switch@0,5 {
> + compatible = "mscc,felix-switch";
> + reg = <0x000500 0 0 0 0>;
> +
> + ethernet-ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* external ports */
> + switch_port0: port@0 {
> + reg = <0>;
> + };
> + switch_port1: port@1 {
> + reg = <1>;
> + };
> + switch_port2: port@2 {
> + reg = <2>;
> + };
> + switch_port3: port@3 {
> + reg = <3>;
> + };
> + /* internal to-cpu ports */
> + port@4 {
> + reg = <4>;
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> + port@5 {
> + reg = <5>;
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> + };
> + };

This sounds like a DSA setup, where you have SoC ports connected to
the switch. With DSA, the CPU ports of the switch are special. We
don't create netdev's for them, the binding explicitly list which SoC
interface they are bound to, etc.

What model are you using here? I'm just trying to understand the setup
to ensure it is consistent with the swichdev model.

Thanks
Andrew

2019-06-24 13:59:23

by Claudiu Manoil

[permalink] [raw]
Subject: RE: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node

Hi Andrew,

>-----Original Message-----
>From: Andrew Lunn <[email protected]>
>Sent: Friday, June 21, 2019 7:50 PM
>To: Claudiu Manoil <[email protected]>
>Cc: David S . Miller <[email protected]>; [email protected];
>Alexandre Belloni <[email protected]>; [email protected];
>Alexandru Marginean <[email protected]>; linux-
>[email protected]; [email protected]; Allan Nielsen
><[email protected]>; Rob Herring <[email protected]>; linux-
>[email protected]
>Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port
>DT node
>
>On Fri, Jun 21, 2019 at 06:38:50PM +0300, Claudiu Manoil wrote:
>> The switch device features 6 ports, 4 with external links
>> and 2 internally facing to the ls1028a SoC and connected via
>> fixed links to 2 internal enetc ethernet controller ports.
>
>Hi Claudiu
>
>> + switch@0,5 {
>> + compatible = "mscc,felix-switch";
>> + reg = <0x000500 0 0 0 0>;
>> +
>> + ethernet-ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + /* external ports */
>> + switch_port0: port@0 {
>> + reg = <0>;
>> + };
>> + switch_port1: port@1 {
>> + reg = <1>;
>> + };
>> + switch_port2: port@2 {
>> + reg = <2>;
>> + };
>> + switch_port3: port@3 {
>> + reg = <3>;
>> + };
>> + /* internal to-cpu ports */
>> + port@4 {
>> + reg = <4>;
>> + fixed-link {
>> + speed = <1000>;
>> + full-duplex;
>> + };
>> + };
>> + port@5 {
>> + reg = <5>;
>> + fixed-link {
>> + speed = <1000>;
>> + full-duplex;
>> + };
>> + };
>> + };
>> + };
>
>This sounds like a DSA setup, where you have SoC ports connected to
>the switch. With DSA, the CPU ports of the switch are special. We
>don't create netdev's for them, the binding explicitly list which SoC
>interface they are bound to, etc.
>
>What model are you using here? I'm just trying to understand the setup
>to ensure it is consistent with the swichdev model.
>

Yeah, there are 2 ethernet controller ports (managed by the enetc driver)
connected inside the SoC via SGMII links to 2 of the switch ports, one of
these switch ports can be configured as CPU port (with follow-up patches).

This configuration may look prettier on DSA, but the main restriction here
is that the entire functionality is provided by the ocelot driver which is a
switchdev driver. I don't think it would be a good idea to copy-paste code
from ocelot to a separate dsa driver.

Thanks for the review.
Claudiu

2019-06-24 14:01:17

by Alexandre Belloni

[permalink] [raw]
Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node

On 24/06/2019 11:45:37+0000, Claudiu Manoil wrote:
> Hi Andrew,
>
> >-----Original Message-----
> >From: Andrew Lunn <[email protected]>
> >Sent: Friday, June 21, 2019 7:50 PM
> >To: Claudiu Manoil <[email protected]>
> >Cc: David S . Miller <[email protected]>; [email protected];
> >Alexandre Belloni <[email protected]>; [email protected];
> >Alexandru Marginean <[email protected]>; linux-
> >[email protected]; [email protected]; Allan Nielsen
> ><[email protected]>; Rob Herring <[email protected]>; linux-
> >[email protected]
> >Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port
> >DT node
> >
> >On Fri, Jun 21, 2019 at 06:38:50PM +0300, Claudiu Manoil wrote:
> >> The switch device features 6 ports, 4 with external links
> >> and 2 internally facing to the ls1028a SoC and connected via
> >> fixed links to 2 internal enetc ethernet controller ports.
> >
> >Hi Claudiu
> >
> >> + switch@0,5 {
> >> + compatible = "mscc,felix-switch";
> >> + reg = <0x000500 0 0 0 0>;
> >> +
> >> + ethernet-ports {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + /* external ports */
> >> + switch_port0: port@0 {
> >> + reg = <0>;
> >> + };
> >> + switch_port1: port@1 {
> >> + reg = <1>;
> >> + };
> >> + switch_port2: port@2 {
> >> + reg = <2>;
> >> + };
> >> + switch_port3: port@3 {
> >> + reg = <3>;
> >> + };
> >> + /* internal to-cpu ports */
> >> + port@4 {
> >> + reg = <4>;
> >> + fixed-link {
> >> + speed = <1000>;
> >> + full-duplex;
> >> + };
> >> + };
> >> + port@5 {
> >> + reg = <5>;
> >> + fixed-link {
> >> + speed = <1000>;
> >> + full-duplex;
> >> + };
> >> + };
> >> + };
> >> + };
> >
> >This sounds like a DSA setup, where you have SoC ports connected to
> >the switch. With DSA, the CPU ports of the switch are special. We
> >don't create netdev's for them, the binding explicitly list which SoC
> >interface they are bound to, etc.
> >
> >What model are you using here? I'm just trying to understand the setup
> >to ensure it is consistent with the swichdev model.
> >
>
> Yeah, there are 2 ethernet controller ports (managed by the enetc driver)
> connected inside the SoC via SGMII links to 2 of the switch ports, one of
> these switch ports can be configured as CPU port (with follow-up patches).
>
> This configuration may look prettier on DSA, but the main restriction here
> is that the entire functionality is provided by the ocelot driver which is a
> switchdev driver. I don't think it would be a good idea to copy-paste code
> from ocelot to a separate dsa driver.
>

We should probably make the ocelot driver a DSA driver then...


--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

2019-06-24 14:34:05

by Andrew Lunn

[permalink] [raw]
Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node

> > Yeah, there are 2 ethernet controller ports (managed by the enetc driver)
> > connected inside the SoC via SGMII links to 2 of the switch ports, one of
> > these switch ports can be configured as CPU port (with follow-up patches).
> >
> > This configuration may look prettier on DSA, but the main restriction here
> > is that the entire functionality is provided by the ocelot driver which is a
> > switchdev driver. I don't think it would be a good idea to copy-paste code
> > from ocelot to a separate dsa driver.
> >
>
> We should probably make the ocelot driver a DSA driver then...

Hi Claudiu, Alexandre

An important part of DSA is being able to direct frames out specific
ports when they ingress via the CPU port. Does the silicon support
this? At the moment, i think it is using polled IO.

Andrew

2019-06-24 19:41:37

by [email protected]

[permalink] [raw]
Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node

Hi Andrew,

The 06/24/2019 16:26, Andrew Lunn wrote:
> > > Yeah, there are 2 ethernet controller ports (managed by the enetc driver)
> > > connected inside the SoC via SGMII links to 2 of the switch ports, one of
> > > these switch ports can be configured as CPU port (with follow-up patches).
> > >
> > > This configuration may look prettier on DSA, but the main restriction here
> > > is that the entire functionality is provided by the ocelot driver which is a
> > > switchdev driver. I don't think it would be a good idea to copy-paste code
> > > from ocelot to a separate dsa driver.
> > >
> >
> > We should probably make the ocelot driver a DSA driver then...
> An important part of DSA is being able to direct frames out specific
> ports when they ingress via the CPU port. Does the silicon support
> this? At the moment, i think it is using polled IO.

That is supported, it requires a bit of initial configuration of the Chip, but
nothing big (I believe this configuration is part of Claudiu's change-set).

But how do you envision this done?

- Let the existing SwitchDev driver and the DSA driver use a set of common
functions.
- Convert the existing Ocelot driver from SwitchDev to DSA
- Fork (copy) the existing driver of Ocelot, and modify it as needed for the
Felix driver

My guess is the first one, but I would like to understand what you have in mind.

BTW: The Ocelot switch does exist in an other (register compatible) version
without the MIPS CPU. That version would use a MAC-2-MAC connection to an
external CPU, and would fit the DSA model. And we have been considering how to
best represent that version in the kernel.

/Allan

2019-06-24 20:13:17

by Andrew Lunn

[permalink] [raw]
Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node

On Mon, Jun 24, 2019 at 05:23:45PM +0200, Allan W. Nielsen wrote:
> Hi Andrew,
>
> The 06/24/2019 16:26, Andrew Lunn wrote:
> > > > Yeah, there are 2 ethernet controller ports (managed by the enetc driver)
> > > > connected inside the SoC via SGMII links to 2 of the switch ports, one of
> > > > these switch ports can be configured as CPU port (with follow-up patches).
> > > >
> > > > This configuration may look prettier on DSA, but the main restriction here
> > > > is that the entire functionality is provided by the ocelot driver which is a
> > > > switchdev driver. I don't think it would be a good idea to copy-paste code
> > > > from ocelot to a separate dsa driver.
> > > >
> > >
> > > We should probably make the ocelot driver a DSA driver then...
> > An important part of DSA is being able to direct frames out specific
> > ports when they ingress via the CPU port. Does the silicon support
> > this? At the moment, i think it is using polled IO.
>
> That is supported, it requires a bit of initial configuration of the Chip, but
> nothing big (I believe this configuration is part of Claudiu's change-set).
>
> But how do you envision this done?
>
> - Let the existing SwitchDev driver and the DSA driver use a set of common
> functions.
> - Convert the existing Ocelot driver from SwitchDev to DSA
> - Fork (copy) the existing driver of Ocelot, and modify it as needed for the
> Felix driver
>
> My guess is the first one, but I would like to understand what you have in mind.

I don't know the various architectures the switch is used in. But it
does seem like a core library, and then a switchdev wrapper for Ocelot
and a DSA wrapper for Felix would make sense.

Andrew

2019-06-24 21:24:00

by Alexandre Belloni

[permalink] [raw]
Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node

On 24/06/2019 18:24:31+0200, Andrew Lunn wrote:
> On Mon, Jun 24, 2019 at 05:23:45PM +0200, Allan W. Nielsen wrote:
> > Hi Andrew,
> >
> > The 06/24/2019 16:26, Andrew Lunn wrote:
> > > > > Yeah, there are 2 ethernet controller ports (managed by the enetc driver)
> > > > > connected inside the SoC via SGMII links to 2 of the switch ports, one of
> > > > > these switch ports can be configured as CPU port (with follow-up patches).
> > > > >
> > > > > This configuration may look prettier on DSA, but the main restriction here
> > > > > is that the entire functionality is provided by the ocelot driver which is a
> > > > > switchdev driver. I don't think it would be a good idea to copy-paste code
> > > > > from ocelot to a separate dsa driver.
> > > > >
> > > >
> > > > We should probably make the ocelot driver a DSA driver then...
> > > An important part of DSA is being able to direct frames out specific
> > > ports when they ingress via the CPU port. Does the silicon support
> > > this? At the moment, i think it is using polled IO.
> >
> > That is supported, it requires a bit of initial configuration of the Chip, but
> > nothing big (I believe this configuration is part of Claudiu's change-set).
> >
> > But how do you envision this done?
> >
> > - Let the existing SwitchDev driver and the DSA driver use a set of common
> > functions.
> > - Convert the existing Ocelot driver from SwitchDev to DSA
> > - Fork (copy) the existing driver of Ocelot, and modify it as needed for the
> > Felix driver
> >
> > My guess is the first one, but I would like to understand what you have in mind.
>
> I don't know the various architectures the switch is used in. But it
> does seem like a core library, and then a switchdev wrapper for Ocelot
> and a DSA wrapper for Felix would make sense.

Ocelot could also be used in a DSA setting where one port can be
connected to an external MAC and be used to inject/extract frames
to/from any other ports. In that case, the IFH would serve as the DSA
tag.


--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

2019-07-05 00:16:20

by Vladimir Oltean

[permalink] [raw]
Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node

On Tue, 25 Jun 2019 at 00:23, Alexandre Belloni
<[email protected]> wrote:
>
> On 24/06/2019 18:24:31+0200, Andrew Lunn wrote:
> > On Mon, Jun 24, 2019 at 05:23:45PM +0200, Allan W. Nielsen wrote:
> > > Hi Andrew,
> > >
> > > The 06/24/2019 16:26, Andrew Lunn wrote:
> > > > > > Yeah, there are 2 ethernet controller ports (managed by the enetc driver)
> > > > > > connected inside the SoC via SGMII links to 2 of the switch ports, one of
> > > > > > these switch ports can be configured as CPU port (with follow-up patches).
> > > > > >
> > > > > > This configuration may look prettier on DSA, but the main restriction here
> > > > > > is that the entire functionality is provided by the ocelot driver which is a
> > > > > > switchdev driver. I don't think it would be a good idea to copy-paste code
> > > > > > from ocelot to a separate dsa driver.
> > > > > >
> > > > >
> > > > > We should probably make the ocelot driver a DSA driver then...
> > > > An important part of DSA is being able to direct frames out specific
> > > > ports when they ingress via the CPU port. Does the silicon support
> > > > this? At the moment, i think it is using polled IO.
> > >
> > > That is supported, it requires a bit of initial configuration of the Chip, but
> > > nothing big (I believe this configuration is part of Claudiu's change-set).
> > >
> > > But how do you envision this done?
> > >
> > > - Let the existing SwitchDev driver and the DSA driver use a set of common
> > > functions.
> > > - Convert the existing Ocelot driver from SwitchDev to DSA
> > > - Fork (copy) the existing driver of Ocelot, and modify it as needed for the
> > > Felix driver
> > >
> > > My guess is the first one, but I would like to understand what you have in mind.
> >
> > I don't know the various architectures the switch is used in. But it
> > does seem like a core library, and then a switchdev wrapper for Ocelot
> > and a DSA wrapper for Felix would make sense.
>
> Ocelot could also be used in a DSA setting where one port can be
> connected to an external MAC and be used to inject/extract frames
> to/from any other ports. In that case, the IFH would serve as the DSA
> tag.
>
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

Hi everyone,

Thank you for the nice discussion.
I've been talking off-list to Claudiu and Alexandru about switchdev vs
DSA for the Felix/Ocelot switches.
My initial reaction was the same as Andrew's - there's a CPU-facing
Ethernet MAC with some vendor-defined injection and extraction
headers? Sounds like DSA.
But then we discussed about what DSA for Felix/Ocelot would look like.
Here are some points to consider:
- DSA is typically used for discrete switches, switchdev is typically
used for embedded ones. As far as I understand from Allan's message,
Ocelot is really an entire switching SoC that's running Linux inside
(on the MIPS CPU) with a switchdev driver. There is no (mainline?)
driver that would control the Ocelot SoC from a higher-level Linux
system. The latter would (maybe) fit DSA more.
- The D in DSA is for cascaded switches. Apart from the absence of
such a "Ocelot SoC" driver (which maybe can be written, I don't know),
I think the switching core itself has some fundamental limitations
that make a DSA implementation questionable:
1. The switch has a single port which can apply these vendor tags.
Also the injection header is different than the extraction header. See
more at #4.
2. The switch will tag all frames that go upstream on this port
towards the CPU, no matter what source port they came from. It can't
be told "hey, don't add a tag for frames coming from this
downstream-facing port, because it's a DSA port and not front-panel,
so there's another switch underneath you who already added a tag to
the frame". So frames that arrive at the CPU through an array of N
cascaded Felix/Ocelot switches will need to be peeled off, one by one,
by N vendor tags.
3. The extraction header does not contain a field for the "switch
id", only for the "source port". This means that if you want to figure
out the switch id, you really *need* to make a topology out of those
stacked vendor tags and figure out which switch it was by counting the
tags. It also means that you can only have Felix/Ocelot in a linear
topology.
4. The switch cannot parse its own vendor tags. This is a big one,
because it means that for an autonomously forwarded frame which
transits two cascaded switches but doesn't reach the CPU, there is no
one in the path who's going to consume the vendor tag. So the frame
will exit the other front-panel port with extra bytes in it.

Ok, let's say that all of the above limitations have one thing in
common - the vendor tags aren't really thought out with DSA-like
setups in mind. In theory it's possible to not use the native tags and
instead implement a dsa_8021q tagger for it. But then, RX timestamps
for PTP are also transmitted to the CPU through this vendor header,
and losing PTP is a big no-no.

So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of
sense if the whole purpose is to hide the CPU-facing netdev.
In a cascaded setup, these switches could only sit at the top of tree,
and ironically, they'd be better modeled as a switchdev DSA master
port than part of the DSA tree itself. Put these switches anywhere
else in the tree and they're just troublemakers.
As for the LS1028A, I think that connecting this embedded switch via
two Ethernet MACs is just poorly thought out design, but that doesn't
mean DSA is going to help it in any way other than perhaps cosmetic.

Regards,
-Vladimir

2019-07-05 04:50:37

by Andrew Lunn

[permalink] [raw]
Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node

Hi Vladimir

> - DSA is typically used for discrete switches, switchdev is typically
> used for embedded ones.

Typically DSA is for discrete switches, but not exclusively. The
b53/SF2 is embedded in a number of Broadcom SoCs. So this is no
different to Ocelot, except ARM vs MIPS. Also, i would disagree that
switchdev is used for embedded ones. Mellonex devices are discrete, on
a PCIe bus. I believe Netronome devices are also discrete PCIe
devices. In fact, i think ocelot is the only embedded switchdev
switch.

So embedded vs discrete plays no role here at all.

> - The D in DSA is for cascaded switches. Apart from the absence of
> such a "Ocelot SoC" driver (which maybe can be written, I don't know),
> I think the switching core itself has some fundamental limitations
> that make a DSA implementation questionable:

There is no requirement to implement D in DSA. In fact, only Marvell
does. None of the other switches do. And you will also find that most
boards with a Marvell switch use a single device. D in DSA is totally
optional. In fact, DSA is built from the ground up that nearly
everything is optional. Take a look at mv88e6060, as an example. It
implements nearly nothing. It cannot even offload a bridge to the
switch.

> So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of
> sense if the whole purpose is to hide the CPU-facing netdev.

You actually convinced me the exact opposite. You described the
headers which are needed to implement DSA. The switch sounds like it
can do what DSA requires. So DSA is the correct model.

Andrew

2019-07-05 08:39:29

by Claudiu Manoil

[permalink] [raw]
Subject: RE: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node

>-----Original Message-----
>From: Andrew Lunn <[email protected]>
>Sent: Friday, July 5, 2019 7:50 AM
>To: Vladimir Oltean <[email protected]>
>Cc: Alexandre Belloni <[email protected]>; Allan W. Nielsen
><[email protected]>; Claudiu Manoil <[email protected]>;
>David S . Miller <[email protected]>; [email protected];
>[email protected]; Alexandru Marginean
><[email protected]>; [email protected];
>[email protected]; Allan Nielsen
><[email protected]>; Rob Herring <[email protected]>; linux-
>[email protected]
>Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port
>DT node
>
>Hi Vladimir
>
>> - DSA is typically used for discrete switches, switchdev is typically
>> used for embedded ones.
>
>Typically DSA is for discrete switches, but not exclusively. The
>b53/SF2 is embedded in a number of Broadcom SoCs. So this is no
>different to Ocelot, except ARM vs MIPS. Also, i would disagree that
>switchdev is used for embedded ones. Mellonex devices are discrete, on
>a PCIe bus. I believe Netronome devices are also discrete PCIe
>devices. In fact, i think ocelot is the only embedded switchdev
>switch.
>
>So embedded vs discrete plays no role here at all.
>
>> - The D in DSA is for cascaded switches. Apart from the absence of
>> such a "Ocelot SoC" driver (which maybe can be written, I don't know),
>> I think the switching core itself has some fundamental limitations
>> that make a DSA implementation questionable:
>
>There is no requirement to implement D in DSA. In fact, only Marvell
>does. None of the other switches do. And you will also find that most
>boards with a Marvell switch use a single device. D in DSA is totally
>optional. In fact, DSA is built from the ground up that nearly
>everything is optional. Take a look at mv88e6060, as an example. It
>implements nearly nothing. It cannot even offload a bridge to the
>switch.
>

Nice discussion, again, but there's a missing point that has not been
brought up yet. We actually intend to support the following hardware
configuration: a single PCI device consisting of the Microsemi's switch core
and our DMA rings.
The hardware supports this configuration into a single PCI function (PF),
with a unique PCI function id (0xe111), so that the same driver has access to
both switch registers and DMA rings connected to the CPU port. This device
would qualify as a switchdev device, and we can simply reuse the existing
ocelot code for the switch core part. The initial patch set was the first step in
supporting the switch core on our platform, we just need to add the support
for the DMA rings part, to make it a complete switchdev solution.

Thanks,
Claudiu

2019-07-05 09:09:43

by Vladimir Oltean

[permalink] [raw]
Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node

Hi Andrew,

On Fri, 5 Jul 2019 at 07:49, Andrew Lunn <[email protected]> wrote:
>
> Hi Vladimir
>
> > - DSA is typically used for discrete switches, switchdev is typically
> > used for embedded ones.
>
> Typically DSA is for discrete switches, but not exclusively. The
> b53/SF2 is embedded in a number of Broadcom SoCs. So this is no
> different to Ocelot, except ARM vs MIPS. Also, i would disagree that
> switchdev is used for embedded ones. Mellonex devices are discrete, on
> a PCIe bus. I believe Netronome devices are also discrete PCIe
> devices. In fact, i think ocelot is the only embedded switchdev
> switch.
>
> So embedded vs discrete plays no role here at all.
>

drivers/staging/fsl-dpaa2/ethsw/ is another example of switchdev
driver for an embedded switch.
I would give it to you that the sample size is probably too small to
say 'typically', but my point was that in order to support cascaded
switches it makes more sense for those to be discrete.

> > - The D in DSA is for cascaded switches. Apart from the absence of
> > such a "Ocelot SoC" driver (which maybe can be written, I don't know),
> > I think the switching core itself has some fundamental limitations
> > that make a DSA implementation questionable:
>
> There is no requirement to implement D in DSA. In fact, only Marvell
> does. None of the other switches do. And you will also find that most
> boards with a Marvell switch use a single device. D in DSA is totally
> optional. In fact, DSA is built from the ground up that nearly
> everything is optional. Take a look at mv88e6060, as an example. It
> implements nearly nothing. It cannot even offload a bridge to the
> switch.
>

Let me see if I get your point.
The D is optional, and the S is optional. So what's left? :)
Also, there's a big difference between "the hardware can't do it" and
"the driver doesn't implement it". If I follow your argument, would
you write a DSA driver for a device that doesn't do L2 switching?
Along that same line, what benefit does the DSA model bring to a
switch that can't do cascading, compared to switchdev? I'm asking this
as a user, not as a developer.

> > So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of
> > sense if the whole purpose is to hide the CPU-facing netdev.
>
> You actually convinced me the exact opposite. You described the
> headers which are needed to implement DSA. The switch sounds like it
> can do what DSA requires. So DSA is the correct model.
>
> Andrew

Somebody actually asked, with the intention of building a board, if
it's possible to cascade the LS1028A embedded switch (Felix) with
discrete SJA1105 devices - Felix being at the top of the switch tree.
Does the DSA model support heterogeneous setups (parsing stacked
headers)? I can't tell if that's how EDSA tags work. With switchdev
for Felix there wouldn't be any problem - it just wouldn't be part of
the DSA tree and its own driver would remove its tags before DSA would
look at the rest.

Regards,
-Vladimir

2019-07-05 13:44:45

by Andrew Lunn

[permalink] [raw]
Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node

> Nice discussion, again, but there's a missing point that has not been
> brought up yet. We actually intend to support the following hardware
> configuration: a single PCI device consisting of the Microsemi's switch core
> and our DMA rings.
> The hardware supports this configuration into a single PCI function (PF),
> with a unique PCI function id (0xe111), so that the same driver has access to
> both switch registers and DMA rings connected to the CPU port. This device
> would qualify as a switchdev device, and we can simply reuse the existing
> ocelot code for the switch core part. The initial patch set was the first step in
> supporting the switch core on our platform, we just need to add the support
> for the DMA rings part, to make it a complete switchdev solution.

Hi Claudiu

It sound like in the end you will have a core library and then two
drivers wrapped around it, giving a pure switchdev device with polled
IO or DMA, and a DSA driver using a CPU port.

Andrew

2019-07-05 14:21:16

by Andrew Lunn

[permalink] [raw]
Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node

> Let me see if I get your point.
> The D is optional, and the S is optional. So what's left? :)

A collection of interfaces.

switchdev and by extension DSA is all about using hardware as an
accelerator. Linux can do switching in software. It can do routing in
software, it can do bonding in software, etc. switchdev gives you an
API to offload this to hardware. And if the hardware or the driver
does not support it, linux will just keep on doing it in software.

Once you get the idea it is just an accelerator, the rest falls into
place. Why there are no new configuration tools, why we expect network
daemons to just work, why users don't need to learn anything new. It
is all just linux networking as normal.

> Also, there's a big difference between "the hardware can't do it" and
> "the driver doesn't implement it". If I follow your argument, would
> you write a DSA driver for a device that doesn't do L2 switching?

Sure i would. Such a device is a port multiplexor. The user sees the
user ports as linux interfaces. They can use those interfaces just
like any other linux interfaces. Configure them using iproute2, add
them to bridges, run bonding, etc. All just linux as normal.

> Along that same line, what benefit does the DSA model bring to a
> switch that can't do cascading, compared to switchdev? I'm asking this
> as a user, not as a developer.

DSA builds on top of switchdev. switchdev gives you an API to offload
things which are happening in software to the hardware. It is the glue
which allows you to configure the accelerator.

There is also a common pattern for some switches. They connect a
switch port MAC to a host port MAC, so that frames can be passed from
the CPU to the switch. This pattern is common enough that
infrastructure has been put in place to support this model. That
infrastructure is DSA.

But that is mostly about details for the driver writer. From the users
perspective, you have a bunch of interfaces which you just use as
normal, and some stuff can get accelerated by the hardware. We don't
want the user to have to known about, or do anything, with the host
port or the switch port it is connected to. DSA very nearly takes care
of everything to do with those two. The only thing you need to do is
configure the master interface up. Then things just work as a bunch of
Linux interfaces.

Now think about a pure switchdev switch, with a port connected to the
host. The model breaks down. How do you use that link to the switch?
It is just a plane link. You would not have tagging in operation. So
you cannot send frames out specific ports. In order to do that, you
need to add vlans, and configure the switch to map vlans to ports,
etc. You also then have two linux interfaces representing one
port. The pure switchdev interface, and the VLAN interface. That is
going to confuse the user. You SNMP agent is not just going to
work. You get the statistics from the pure switchdev interface, but
the IP configuration from the vlan interface? How do you bridge two
ports together? You need to put the same VLAN on two interfaces. Where
as the DSA model you just use linux as normal and create a bridge, add
the two interfaces, and then the stack transparently offloads it to
the accelerator. How does STP work?

Using DSA without using the D means switch ports just work as linux
interfaces.

>
> > > So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of
> > > sense if the whole purpose is to hide the CPU-facing netdev.
> >
> > You actually convinced me the exact opposite. You described the
> > headers which are needed to implement DSA. The switch sounds like it
> > can do what DSA requires. So DSA is the correct model.
> >
> > Andrew
>
> Somebody actually asked, with the intention of building a board, if
> it's possible to cascade the LS1028A embedded switch (Felix) with
> discrete SJA1105 devices - Felix being at the top of the switch tree.

Florian has done something very similar. He used a Broadcom SoC with
an in built SF2 switch, and an external B53 roboswitch connected to
one of the SF2 ports. But in that setup, the master interface for the
b53 is a slave port of the SF2. Configure everything in device tree,
bring up the SoC master interface, then the SF2 port acting as a
master interface for the B53, and everything just worked. You have a
bunch of Linux interfaces you can just use as normal.

This is not using D in DSA. It is two instances of DSA. But because
the model is that you get normal linux interfaces, it just works. I
don't see why you cannot do the same with a LS1028A and a SJA1105.

Andrew

2019-07-05 16:43:48

by Florian Fainelli

[permalink] [raw]
Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node



On 7/5/2019 2:08 AM, Vladimir Oltean wrote:
> Hi Andrew,
>
> On Fri, 5 Jul 2019 at 07:49, Andrew Lunn <[email protected]> wrote:
>>
>> Hi Vladimir
>>
>>> - DSA is typically used for discrete switches, switchdev is typically
>>> used for embedded ones.
>>
>> Typically DSA is for discrete switches, but not exclusively. The
>> b53/SF2 is embedded in a number of Broadcom SoCs. So this is no
>> different to Ocelot, except ARM vs MIPS. Also, i would disagree that
>> switchdev is used for embedded ones. Mellonex devices are discrete, on
>> a PCIe bus. I believe Netronome devices are also discrete PCIe
>> devices. In fact, i think ocelot is the only embedded switchdev
>> switch.
>>
>> So embedded vs discrete plays no role here at all.
>>
>
> drivers/staging/fsl-dpaa2/ethsw/ is another example of switchdev
> driver for an embedded switch.
> I would give it to you that the sample size is probably too small to
> say 'typically', but my point was that in order to support cascaded
> switches it makes more sense for those to be discrete.
>
>>> - The D in DSA is for cascaded switches. Apart from the absence of
>>> such a "Ocelot SoC" driver (which maybe can be written, I don't know),
>>> I think the switching core itself has some fundamental limitations
>>> that make a DSA implementation questionable:
>>
>> There is no requirement to implement D in DSA. In fact, only Marvell
>> does. None of the other switches do. And you will also find that most
>> boards with a Marvell switch use a single device. D in DSA is totally
>> optional. In fact, DSA is built from the ground up that nearly
>> everything is optional. Take a look at mv88e6060, as an example. It
>> implements nearly nothing. It cannot even offload a bridge to the
>> switch.
>>
>
> Let me see if I get your point.
> The D is optional, and the S is optional. So what's left? :)
> Also, there's a big difference between "the hardware can't do it" and
> "the driver doesn't implement it". If I follow your argument, would
> you write a DSA driver for a device that doesn't do L2 switching?
> Along that same line, what benefit does the DSA model bring to a
> switch that can't do cascading, compared to switchdev? I'm asking this
> as a user, not as a developer.

As an user, I don't think there are compelling arguments to either
switchdev or DSA because the end result is the same: network devices
that can offload "stuff". As a developer though, there is much less code
to write with DSA than with switchdev to get your HW live.

>
>>> So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of
>>> sense if the whole purpose is to hide the CPU-facing netdev.
>>
>> You actually convinced me the exact opposite. You described the
>> headers which are needed to implement DSA. The switch sounds like it
>> can do what DSA requires. So DSA is the correct model.
>>
>> Andrew
>
> Somebody actually asked, with the intention of building a board, if
> it's possible to cascade the LS1028A embedded switch (Felix) with
> discrete SJA1105 devices - Felix being at the top of the switch tree.
> Does the DSA model support heterogeneous setups (parsing stacked
> headers)? I can't tell if that's how EDSA tags work. With switchdev
> for Felix there wouldn't be any problem - it just wouldn't be part of
> the DSA tree and its own driver would remove its tags before DSA would
> look at the rest.

DSA not does not make any particular assumptions about how the stacking
is done actually because each slave network device is expected to
provided standard Ethernet frames to the network stack. How you get to
that point is entirely specific to what the hardware can do.

You do what Andrew described about one of my setup (bcm_sf2 w/ tagging
enabled and b53 w/o tagging, see more below why [1]]) and both being
discrete switch trees, with the master netdev of the b53 being a slave
netdev provided by bcm_sf2. If your tagging protocol supports it you can
make them part of the same DSA switch tree and just have them have
different switch identifiers, that is what Marvell switches do and it
works just great. In your case, I suppose you could even use double VLAN
tagging to get such cascading to work, that would limit you to a two
level of cascading, unless you invent something custom.

[1]: The original Broadcom tag format introduced with BCM5325/5365 did
support cascading in the same way that Marvell did where a switch
identifier can be added in addition to a port number within the tag. The
newest Broadcom tag that was introduced with 5395 and newer dropped
support for the switch identifier and the switch will "terminate" the
first (from start of Ethernet frame) tag that it receives. This is the
reason why we need to disable tagging on the outermost B53 device that
we are connected to. This means those network devices are mainly
configuration endpoints and not passing data (DSA_TAG_PROTO_NONE),
though we could use DSA_TAG_PROTO_8021Q and resolve that now.
--
Florian

2019-07-07 22:55:36

by Florian Fainelli

[permalink] [raw]
Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node



On 7/7/2019 2:00 PM, Vladimir Oltean wrote:
> On Fri, 5 Jul 2019 at 19:03, Florian Fainelli <[email protected]> wrote:
>>
>>
>>
>> On 7/5/2019 2:08 AM, Vladimir Oltean wrote:
>>> Hi Andrew,
>>>
>>> On Fri, 5 Jul 2019 at 07:49, Andrew Lunn <[email protected]> wrote:
>>>>
>>>> Hi Vladimir
>>>>
>>>>> - DSA is typically used for discrete switches, switchdev is typically
>>>>> used for embedded ones.
>>>>
>>>> Typically DSA is for discrete switches, but not exclusively. The
>>>> b53/SF2 is embedded in a number of Broadcom SoCs. So this is no
>>>> different to Ocelot, except ARM vs MIPS. Also, i would disagree that
>>>> switchdev is used for embedded ones. Mellonex devices are discrete, on
>>>> a PCIe bus. I believe Netronome devices are also discrete PCIe
>>>> devices. In fact, i think ocelot is the only embedded switchdev
>>>> switch.
>>>>
>>>> So embedded vs discrete plays no role here at all.
>>>>
>>>
>>> drivers/staging/fsl-dpaa2/ethsw/ is another example of switchdev
>>> driver for an embedded switch.
>>> I would give it to you that the sample size is probably too small to
>>> say 'typically', but my point was that in order to support cascaded
>>> switches it makes more sense for those to be discrete.
>>>
>>>>> - The D in DSA is for cascaded switches. Apart from the absence of
>>>>> such a "Ocelot SoC" driver (which maybe can be written, I don't know),
>>>>> I think the switching core itself has some fundamental limitations
>>>>> that make a DSA implementation questionable:
>>>>
>>>> There is no requirement to implement D in DSA. In fact, only Marvell
>>>> does. None of the other switches do. And you will also find that most
>>>> boards with a Marvell switch use a single device. D in DSA is totally
>>>> optional. In fact, DSA is built from the ground up that nearly
>>>> everything is optional. Take a look at mv88e6060, as an example. It
>>>> implements nearly nothing. It cannot even offload a bridge to the
>>>> switch.
>>>>
>>>
>>> Let me see if I get your point.
>>> The D is optional, and the S is optional. So what's left? :)
>>> Also, there's a big difference between "the hardware can't do it" and
>>> "the driver doesn't implement it". If I follow your argument, would
>>> you write a DSA driver for a device that doesn't do L2 switching?
>>> Along that same line, what benefit does the DSA model bring to a
>>> switch that can't do cascading, compared to switchdev? I'm asking this
>>> as a user, not as a developer.
>>
>> As an user, I don't think there are compelling arguments to either
>> switchdev or DSA because the end result is the same: network devices
>> that can offload "stuff". As a developer though, there is much less code
>> to write with DSA than with switchdev to get your HW live.
>>
>>>
>>>>> So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of
>>>>> sense if the whole purpose is to hide the CPU-facing netdev.
>>>>
>>>> You actually convinced me the exact opposite. You described the
>>>> headers which are needed to implement DSA. The switch sounds like it
>>>> can do what DSA requires. So DSA is the correct model.
>>>>
>>>> Andrew
>>>
>>> Somebody actually asked, with the intention of building a board, if
>>> it's possible to cascade the LS1028A embedded switch (Felix) with
>>> discrete SJA1105 devices - Felix being at the top of the switch tree.
>>> Does the DSA model support heterogeneous setups (parsing stacked
>>> headers)? I can't tell if that's how EDSA tags work. With switchdev
>>> for Felix there wouldn't be any problem - it just wouldn't be part of
>>> the DSA tree and its own driver would remove its tags before DSA would
>>> look at the rest.
>>
>> DSA not does not make any particular assumptions about how the stacking
>> is done actually because each slave network device is expected to
>> provided standard Ethernet frames to the network stack. How you get to
>> that point is entirely specific to what the hardware can do.
>>
>> You do what Andrew described about one of my setup (bcm_sf2 w/ tagging
>> enabled and b53 w/o tagging, see more below why [1]]) and both being
>> discrete switch trees, with the master netdev of the b53 being a slave
>> netdev provided by bcm_sf2. If your tagging protocol supports it you can
>> make them part of the same DSA switch tree and just have them have
>> different switch identifiers, that is what Marvell switches do and it
>> works just great. In your case, I suppose you could even use double VLAN
>> tagging to get such cascading to work, that would limit you to a two
>> level of cascading, unless you invent something custom.
>>
>> [1]: The original Broadcom tag format introduced with BCM5325/5365 did
>> support cascading in the same way that Marvell did where a switch
>> identifier can be added in addition to a port number within the tag. The
>> newest Broadcom tag that was introduced with 5395 and newer dropped
>> support for the switch identifier and the switch will "terminate" the
>> first (from start of Ethernet frame) tag that it receives. This is the
>> reason why we need to disable tagging on the outermost B53 device that
>> we are connected to. This means those network devices are mainly
>> configuration endpoints and not passing data (DSA_TAG_PROTO_NONE),
>> though we could use DSA_TAG_PROTO_8021Q and resolve that now.
>> --
>> Florian
>
> Thanks to both of you for sharing this trick, I don't think it's
> written "in the books".
> Given that you can choose the boundaries of a DSA tree at will
> depending on what suits the setup best (and e.g. turn a DSA link pair
> into a master and a CPU port pair which gains back introspection into
> that port's ethtool counters etc), I guess DSA doesn't really offer
> anything that raw switchdev drivers can't do (by reimplementing part
> of it), just that it's is more idiomatic for Ethernet-connected
> switches?
> If so, it's a bit strange that switchdev and DSA are not in fact
> unified, because as it is it creates false dichotomies. What about the
> other way around? What are the features that raw switchdev drivers
> (nfp, rocker, mlxsw) need that DSA can't offer them without breaking
> the general model? (apart from access to the raw ndo_start_xmit and a
> NAPI context for rcv)

I don't think they need anything that DSA could not offer them, other
than having the ability to complete bypass the net_device registration
and standard methods offered by DSA and provide their own.

> As for DSA being easier on the driver writer, I totally get that, but
> I think it isn't that much of an argument when the switchdev driver is
> already said and done, as in this case :)


DSA and switchdev don't try to solve the same problems, switchdev is
only about providing the mechanics by which the networking stack can
offload certain objects: FDB, MDB, VLANs, VXLANs, bridge attributes etc
towards capable devices. It is largely stateless and does not care so
much about what kind of device is on the other end of the notifications
it sends.

DSA is all about creating a device driver model for Ethernet switches
that follow the paradigm of having a seemingly standard Ethernet MAC
(doing DMA) connected to one or more Ethernet switch devices and between
those devices, a data path allows the identification of each Ethernet
frame as ingressing/egressing towards a particular switch port in the
fabric. With DSA you are supposed to be able to swap your Ethernet MAC
driver (e.g.: mv643xx_eth, e1000e, igb, bcmsysport, bcmgenet, etc.) with
any switch device (mv88e6xxx, b53, qca8k, etc.) and things would still
work largely the same (minus switch driver differences obviously).

In that regard, DSA also provides you with a number of things "for free"
to try to push the standard Linux device driver model further:
integration with PHYLIB/PHYLINK, HWMON, ethtool, etc. etc.
--
Florian

2019-07-07 22:55:59

by Vladimir Oltean

[permalink] [raw]
Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node

On Fri, 5 Jul 2019 at 19:03, Florian Fainelli <[email protected]> wrote:
>
>
>
> On 7/5/2019 2:08 AM, Vladimir Oltean wrote:
> > Hi Andrew,
> >
> > On Fri, 5 Jul 2019 at 07:49, Andrew Lunn <[email protected]> wrote:
> >>
> >> Hi Vladimir
> >>
> >>> - DSA is typically used for discrete switches, switchdev is typically
> >>> used for embedded ones.
> >>
> >> Typically DSA is for discrete switches, but not exclusively. The
> >> b53/SF2 is embedded in a number of Broadcom SoCs. So this is no
> >> different to Ocelot, except ARM vs MIPS. Also, i would disagree that
> >> switchdev is used for embedded ones. Mellonex devices are discrete, on
> >> a PCIe bus. I believe Netronome devices are also discrete PCIe
> >> devices. In fact, i think ocelot is the only embedded switchdev
> >> switch.
> >>
> >> So embedded vs discrete plays no role here at all.
> >>
> >
> > drivers/staging/fsl-dpaa2/ethsw/ is another example of switchdev
> > driver for an embedded switch.
> > I would give it to you that the sample size is probably too small to
> > say 'typically', but my point was that in order to support cascaded
> > switches it makes more sense for those to be discrete.
> >
> >>> - The D in DSA is for cascaded switches. Apart from the absence of
> >>> such a "Ocelot SoC" driver (which maybe can be written, I don't know),
> >>> I think the switching core itself has some fundamental limitations
> >>> that make a DSA implementation questionable:
> >>
> >> There is no requirement to implement D in DSA. In fact, only Marvell
> >> does. None of the other switches do. And you will also find that most
> >> boards with a Marvell switch use a single device. D in DSA is totally
> >> optional. In fact, DSA is built from the ground up that nearly
> >> everything is optional. Take a look at mv88e6060, as an example. It
> >> implements nearly nothing. It cannot even offload a bridge to the
> >> switch.
> >>
> >
> > Let me see if I get your point.
> > The D is optional, and the S is optional. So what's left? :)
> > Also, there's a big difference between "the hardware can't do it" and
> > "the driver doesn't implement it". If I follow your argument, would
> > you write a DSA driver for a device that doesn't do L2 switching?
> > Along that same line, what benefit does the DSA model bring to a
> > switch that can't do cascading, compared to switchdev? I'm asking this
> > as a user, not as a developer.
>
> As an user, I don't think there are compelling arguments to either
> switchdev or DSA because the end result is the same: network devices
> that can offload "stuff". As a developer though, there is much less code
> to write with DSA than with switchdev to get your HW live.
>
> >
> >>> So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of
> >>> sense if the whole purpose is to hide the CPU-facing netdev.
> >>
> >> You actually convinced me the exact opposite. You described the
> >> headers which are needed to implement DSA. The switch sounds like it
> >> can do what DSA requires. So DSA is the correct model.
> >>
> >> Andrew
> >
> > Somebody actually asked, with the intention of building a board, if
> > it's possible to cascade the LS1028A embedded switch (Felix) with
> > discrete SJA1105 devices - Felix being at the top of the switch tree.
> > Does the DSA model support heterogeneous setups (parsing stacked
> > headers)? I can't tell if that's how EDSA tags work. With switchdev
> > for Felix there wouldn't be any problem - it just wouldn't be part of
> > the DSA tree and its own driver would remove its tags before DSA would
> > look at the rest.
>
> DSA not does not make any particular assumptions about how the stacking
> is done actually because each slave network device is expected to
> provided standard Ethernet frames to the network stack. How you get to
> that point is entirely specific to what the hardware can do.
>
> You do what Andrew described about one of my setup (bcm_sf2 w/ tagging
> enabled and b53 w/o tagging, see more below why [1]]) and both being
> discrete switch trees, with the master netdev of the b53 being a slave
> netdev provided by bcm_sf2. If your tagging protocol supports it you can
> make them part of the same DSA switch tree and just have them have
> different switch identifiers, that is what Marvell switches do and it
> works just great. In your case, I suppose you could even use double VLAN
> tagging to get such cascading to work, that would limit you to a two
> level of cascading, unless you invent something custom.
>
> [1]: The original Broadcom tag format introduced with BCM5325/5365 did
> support cascading in the same way that Marvell did where a switch
> identifier can be added in addition to a port number within the tag. The
> newest Broadcom tag that was introduced with 5395 and newer dropped
> support for the switch identifier and the switch will "terminate" the
> first (from start of Ethernet frame) tag that it receives. This is the
> reason why we need to disable tagging on the outermost B53 device that
> we are connected to. This means those network devices are mainly
> configuration endpoints and not passing data (DSA_TAG_PROTO_NONE),
> though we could use DSA_TAG_PROTO_8021Q and resolve that now.
> --
> Florian

Thanks to both of you for sharing this trick, I don't think it's
written "in the books".
Given that you can choose the boundaries of a DSA tree at will
depending on what suits the setup best (and e.g. turn a DSA link pair
into a master and a CPU port pair which gains back introspection into
that port's ethtool counters etc), I guess DSA doesn't really offer
anything that raw switchdev drivers can't do (by reimplementing part
of it), just that it's is more idiomatic for Ethernet-connected
switches?
If so, it's a bit strange that switchdev and DSA are not in fact
unified, because as it is it creates false dichotomies. What about the
other way around? What are the features that raw switchdev drivers
(nfp, rocker, mlxsw) need that DSA can't offer them without breaking
the general model? (apart from access to the raw ndo_start_xmit and a
NAPI context for rcv)
As for DSA being easier on the driver writer, I totally get that, but
I think it isn't that much of an argument when the switchdev driver is
already said and done, as in this case :)

Regards,
-Vladimir