OpenWrt 21.02.0 third release candidate

DSA does (transparently) offload to the switch fabric, inter-LAN traffic is accordingly handled within the switch fabric, in hardware - at line speed, and never seen by the SOC's CPU.

Edit: Just to take an example, the realtek target with its single-core 500 MHz RTL83xx mips4k SOC has a rather underpowered CPU (it's fast enough to run luci smoothly, but you don't want it to do routing at any meaningful WAN speed), but it does support devices with 8 to 52 1000 MBit/s ethernet ports (including some 10 GBit/s ports for RTL93xx), it does use a DSA switch driver and does deliver full speed and features like link aggregation and similar at line-speed of the switch fabric (so e.g. 48 GBit/s for the gs1900-48).

8 Likes

I am seeing in dmesg that mv88e6xxx_probe is being called twice during boot per the following printk on a WRT3200ACM. Shouldn't the probe only be called once?

mv88e6085 f1072004.mdio-mii:00: switch 0x3520 detected: Marvell 88E6352, revision 1

[Sat Jul  3 21:28:33 2021] libphy: Fixed MDIO Bus: probed
[Sat Jul  3 21:28:33 2021] libphy: orion_mdio_bus: probed
[Sat Jul  3 21:28:33 2021] mv88e6085 f1072004.mdio-mii:00: switch 0x3520 detected: Marvell 88E6352, revision 1
[Sat Jul  3 21:28:33 2021] libphy: mv88e6xxx SMI: probed
[Sat Jul  3 21:28:33 2021] mvneta_bm f10c8000.bm: Buffer Manager for network controller enabled
[Sat Jul  3 21:28:33 2021] mvneta f1070000.ethernet eth0: Using hardware mac address 30:23:03:df:49:28
[Sat Jul  3 21:28:33 2021] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_
netfilter if you need this.
[Sat Jul  3 21:28:33 2021] mv88e6085 f1072004.mdio-mii:00: switch 0x3520 detected: Marvell 88E6352, revision 1
[Sat Jul  3 21:28:33 2021] libphy: mv88e6xxx SMI: probed
[Sat Jul  3 21:28:34 2021] mv88e6085 f1072004.mdio-mii:00 lan4 (uninitialized): PHY [mv88e6xxx-1:00] driver [Marvell 88E1540] (irq=6
4)
[Sat Jul  3 21:28:34 2021] mv88e6085 f1072004.mdio-mii:00 lan3 (uninitialized): PHY [mv88e6xxx-1:01] driver [Marvell 88E1540] (irq=65)
[Sat Jul  3 21:28:34 2021] mv88e6085 f1072004.mdio-mii:00 lan2 (uninitialized): PHY [mv88e6xxx-1:02] driver [Marvell 88E1540] (irq=66)
[Sat Jul  3 21:28:34 2021] mv88e6085 f1072004.mdio-mii:00 lan1 (uninitialized): PHY [mv88e6xxx-1:03] driver [Marvell 88E1540] (irq=67)
[Sat Jul  3 21:28:34 2021] mv88e6085 f1072004.mdio-mii:00 wan (uninitialized): PHY [mv88e6xxx-1:04] driver [Marvell 88E1540] (irq=68)
[Sat Jul  3 21:28:34 2021] mv88e6085 f1072004.mdio-mii:00: configuring for fixed/ link mode
[Sat Jul  3 21:28:34 2021] DSA: tree 0 setup

Yep, a DSA capable switch chipset still works as a plain standard ethernet switch. And switch tags are pushed or popped in hardware by the switch. But it can bite you at L2 in case you have set up a bridge between some ethernet ports of the switch and the WiFI interfaces. Traffic between ethernet ports and WiFi interfaces has to pass the CPU, i.e. the CPU needs to push or pop the switch tags. I hope we'll see more linux drivers for hardware offloading (routing, NAT, PPPoE and so on). Unfortunately some vendors of switch chipsets declared their offloading APIs a state secret.

3 Likes

Oh, thanks, that is very interesting.

That's probably one reason why wifi download speed is limited on this MT7621 AC1300 2x2 device:

Sorry for the screenshot in French : Mo/s == MB/s

Even if that doesn't explain why the upload speed is so low in my case:

There is no material difference between swconfig or dsa in this regard, hardware offloading of wireless interrupts and processing is an orthogonal question (e.g. NSS).

1 Like

Found a number of bugs in rc3 for link aggregation LuCI interface.

Also looking for some guidance what additional manual tweaks are needed to make it work.

is that MT76 benchmark with hardware offloading enabled (in Luci firewall section)?

If this is really true, then I would install a dumb/unmanaged switch for all LAN devices and connect this switch to the router. As a consequence only traffic, which needs routing, goes to the router.

yes, SW+HW offloading on ... but it appears that HW offloading is broken in actual builds => OpenWrt 21.02.0 third release candidate - #126 by danghuy1994

Edit: thanks for asking, so I made an upload test without HW offloading, and it is better:

image

No difference in download speed, 67MB/s
These tests were made with an Intel AX200 card on my laptop and a Cudy wr1300 AP (so: 866.7 Mbit/s, 80 MHz, VHT-MCS 9, VHT-NSS 2, Short GI)

Edit 2:

Edit 3:
I made more testing, and I'm so sorry, in fact it seems to have no difference:

  • with or without sw offloading
  • with or without hw offloading

I have now 40 MBps instead of 31 simply because I moved my laptop a few cm
oops

Under OpenWRT 21.02-rc3 ?

Yes (well, up to 28 ports in the form of the DGS-1210-28 rev F1, gs1900-48 support is pending).

https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=refs/heads/openwrt-21.02

It starts to be days now between the updates…

Is there any clue for the future if we are expecting a RC4 or a formal release soon?

1 Like

Right but take a look at LuCI commits, there have been a ton of fixes since rc3. If there was a fix you needed you can always install a 21.02-snapshot.

The Luci commits you refers to is also two days old now, this was in the beginning only hours…
The master branch seems to be where the works are happening now.

But I thought more like this forum tread is 160 posts now and we actually now discuss more how a network router cpu and a switch works than actual faults. We should probably need a big DSA tread where everyone can discuss how DSA works because it seems to be a hot topic.

So from my viewpoint it feels like 21.02 need to try its wings or it will probably never really fly because it will never be fault free, in the best of worlds that version will be named 21.02.7 or maybe 8.
Alternatively what exactly are we waiting for now?

I would be very happy to see the bug regarding DHCPv6 fixed soon (no leases and no IPv6-PD if leasetime <12h)

1 Like

It appears to me that the processing overhead for DSA's switch tags is a little bit larger than for VLAN tags. If I understand DSA correctly the VLAN tags are replaced with the DSA tags, at least for the top VLAN tag. Do you happen to know how VLAN tagged ports forwarding several VLANs are handled by DSA? Does that also work with just a switch tag and the switch chipset inserts the corresponding VLAN tag for egress frames? Or does the CPU need to push the VLAN tag and the switch tag?

No worries! Ethernet traffic between switch ports is handled by the switch chipset. So you get also full throughput with DSA. And I'd like to add that WiFi bridged traffic has to pass the CPU too, since the WiFi interfaces are connected to the CPU.

The 5.10 kernel is getting some speed improvements:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=64ed3d80567280e5cccb4c4642464223862dabc6

Sadly, 21.01 comes with the 5.4:

2 Likes

This pages shows what a DSA tag looks like for Marvell based switch devices:

https://www.tcpdump.org/linktypes/LINKTYPE_DSA_TAG_DSA.html

3 Likes

Good post, didn't notice that on the rc2 thread. Can't we just install kernel 5.10 on most devices though and get these improvements? I know many people are running 5.10 on mvebu with little to no issues.