@ParanoidZoid it's a fairly simple one as the mvebu kernel enables DSA.
Is it not the other way around? The swconfig marvell driver will never make it upstream. The DSA driver already is.
1 Like
It seems to me that dual CPU interfaces is a major issue if DSA doesn't handle it.
A local patch can be carried to fix. The main issue is how to distribute the load between multiple interfaces. One suggestion is alternating the interfaces for the ports. The other one is using one interface for 4 ports and one interfaces for the WAN port. Another suggestion was to bridge both interfaces such that the load would be automatically balanced. Probably increases latency though. Also not all switches support bridging.
Upstream can't decide basically.
My bad, should have clarified what I meant by upstream - I was referring to OpenWrt trunk. Apologies for the confusion!
And yeah, the article I linked in my last point did discuss swconfig vs. switchdev vs. DSA. It also mentioned how swconfig was rejected by upstream linux.
I'm not exactly a dev, just a hobbyist, so I'm still getting around the terminology.
As a thought for the future, that patch disabled it in the DTS for specific boards. They can be made "okay" on a board-by-board basis.
Also, DTS is "last in wins" -- it is very common practice for an #include-ed DTS to declare things disabled, with the more specific one enabling it later. Or even for an intermediate to enable, before being disabled again.
1 Like
Huh, I guess you can make VLANs in LuCI with DSA after all. But in Network-> Interfaces, not Network-> Switch.
@neheb If it's no trouble at all, would you mind sharing that patch? I've made this but I'm not sure if it's entirely correct (or even if Blogic's 075-dsa-inherit-parent-mac.patch is necessary for mvebu). I also got rid of eth1.2 and eth0.1 from a comment I found (I assume this is just kept for not breaking people's sysupgrades). Besides not restoring the config from an swconfig build and flashing from factory (which I've kept on my other partition), are there any other considerations?
EDIT: Might as well tag @jeff for a second opinion because I'm super new to this closer-to-hardware dev stuff 
Test if your VLAN config is working carefully. At least with the device I was working with I couldn't get VLAN NNNN to be tagged on my trunking phy and untagged on the "LAN" phys. IPQ4019 is a different piece of hardware, but that was a non-starter for me which finished my DSA drive on that device.
The following may help resolve mysterious panics, if present with your hardware:
THIS IS ONLY A PORTION OF THE ORIGINAL PATCH!!!
Protects against NPE for cases where the DSA port is null
Originally from:
From 061f6a505ac33659eab007731c0f6374df39ab55 Mon Sep 17 00:00:00 2001
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 20 Feb 2019 14:35:39 -0800
Subject: [PATCH] net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/dsa/port.c | 12 +++++++---
net/dsa/slave.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
net/dsa/switch.c | 42 +++++++++++++++++++++++++++++++++
3 files changed, 121 insertions(+), 4 deletions(-)
THIS IS ONLY A PORTION OF THE ORIGINAL PATCH!!!
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -255,7 +255,10 @@ int dsa_port_vlan_add(struct dsa_port *d
if (netif_is_bridge_master(vlan->obj.orig_dev))
return -EOPNOTSUPP;
- if (br_vlan_enabled(dp->bridge_dev))
+ /* Can be called from dsa_slave_port_obj_add() or
+ * dsa_slave_vlan_rx_add_vid()
+ */
+ if (!dp->bridge_dev || br_vlan_enabled(dp->bridge_dev))
return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_ADD, &info);
return 0;
@@ -270,10 +273,13 @@ int dsa_port_vlan_del(struct dsa_port *d
.vlan = vlan,
};
- if (netif_is_bridge_master(vlan->obj.orig_dev))
+ if (vlan->obj.orig_dev && netif_is_bridge_master(vlan->obj.orig_dev))
return -EOPNOTSUPP;
- if (br_vlan_enabled(dp->bridge_dev))
+ /* Can be called from dsa_slave_port_obj_del() or
+ * dsa_slave_vlan_rx_kill_vid()
+ */
+ if (!dp->bridge_dev || br_vlan_enabled(dp->bridge_dev))
return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_DEL, &info);
return 0;
Would Openwrt accept this and merge these patches?
I believe you just have to delete things in the patches, from what I've read there's a patch to disable DSA, another to enable swconfig. if you modify these two you can get DSA enabled I believe.
Also we can't forget to change the default config script
Assuming that it provided tangible benefit to users of the device, did not adversely impact other use cases of the device or other users, was coded to meet the standards of project, was aligned with upstream Linux, was easily maintainable, ... , sure, it would be considered.
We'll, I see some benefits, namely:
- Igmp/mld snooping (Wich currently doesn't work and floods streams in all interfaces)
- Bridge offloading freeing the CPU from tasks that the switch can do
- Allow for 802.1x authentication
- Per port statistics
I believe that this are not than enough benefits, don't you think?
I'm really excited about this and I'd be interested in testing this in my own router, I'm tired of having all my ports flooded with multicast traffic.
I would like to request for you to re-read my previous post. I did make an attempt to address (1) the patch that disables DSA and (3) modify the default config script but I can't find (2) the patch that handles/"enables" swconfig. I apologize if the link was not obvious, but I'll post it here again. This time, in a far more visible manner:
https://github.com/jeolives/openwrt/commit/4de76e48b9ddacb63d058d1620f0a36ab6072448
However, I think that a candidate for (3) may be this commit but I am not sure. Please confirm.
EDIT: Also this:
Might also want to get rid of swconfig from the kernel config.
I force pushed some changes in this version. In blogic's staging tree, he didn't remove swconfig from the kconfig, but he did remove references to the driver that depended on it.
EDIT: My .config looks like this after my changes.
An interesting thing to remember about the build system is that the same kernel is typically used for all boards on a given target. That should give you some insight as to why the kernel module was not removed.
Do you really need to add a patch to enable DSA? I believe that you only need to neutralize the ones that disable it, because upstrem(linux kernel) it is automatically enabled, am I wrong?
Does that mean that you can now build a image?
@jeff @neheb Thanks for your help guys! I got it working just fine with a version 5 of my commit on my WRT1900ACSv2-GB.
Thu Mar 14 03:14:19 2019 kern.notice kernel: [ 1.416863] Registering SWP/SWPB emulation handler
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 1.423145] mv88e6085 f1072004.mdio-mii:00: switch 0x1760 detected: Marvell 88E6176, revision 1
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 1.573544] libphy: mv88e6xxx SMI: probed
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 1.577593] DSA: switch 0 0 parsed
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 1.581010] DSA: tree 0 parsed
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 1.846552] Marvell 88E1540 mv88e6xxx-1:00: attached PHY driver [Marvell 88E1540] (mii_bus:phy_addr=mv88e6xxx-1:00, irq=POLL)
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 1.956551] Marvell 88E1540 mv88e6xxx-1:01: attached PHY driver [Marvell 88E1540] (mii_bus:phy_addr=mv88e6xxx-1:01, irq=POLL)
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 2.064489] Marvell 88E1540 mv88e6xxx-1:02: attached PHY driver [Marvell 88E1540] (mii_bus:phy_addr=mv88e6xxx-1:02, irq=POLL)
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 2.176550] Marvell 88E1540 mv88e6xxx-1:03: attached PHY driver [Marvell 88E1540] (mii_bus:phy_addr=mv88e6xxx-1:03, irq=POLL)
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 2.284489] Marvell 88E1540 mv88e6xxx-1:04: attached PHY driver [Marvell 88E1540] (mii_bus:phy_addr=mv88e6xxx-1:04, irq=POLL)
Side note: The LuCI Switch section disappeared so I guess that won't be a problem anymore. I also had to change the LED trigger from ethX to wan.
Of course I haven't really tested stability yet. I also haven't tested VLAN functionality. Literally just booted.
@tiagogaspar8 Yep I can confirm it works. But you have to flash from factory/don't tick "Keep Settings". I mean I can build an image - but I don't know what packages you want/need so it's probably best if you could build it yourself.
Just use the patch linked below in your openwrt build directory via
patch -p1 -i name-of-patch.patch
It will work with the current master as of 17cb490
https://github.com/jeolives/openwrt/commit/fd66eec5f0be614982ee890a61457d269d9afd24.patch
Also with regards to sending this to openwrt trunk, this will probably get rejected.
You mean "bonding"/"load balancing"? Marvell switches that support DSA management should support bonding as well. Refer to Linksys GPL code or Marvell 88E6095 datasheet for more details.
I've even tried porting the bonding code to OpenWrt master (swconfig VLAN based) but I'm not very clear which registers to wrote.
Marvell Armada 385 SoC also supports HW NAT acceleration, which is advertised as Accelerated Data Path. However there is no source code available yet (only available with NDA?). I wonder if Turris Omnia team will bother porting the feature to upstream flow offload infrastructure.
Shouldn't be an issue here then. I wonder which switches don't do bonding...
Turris Omnia already does line rate. It can potentially help with OpenVPN but I doubt it.
@ParanoidZoid switch section is swconfig. Expected behavior since you removed it.
It will not get rejected if you also write an swconfig to DSA migration script.