Hey Everyone!
I'd like some help and to discuss a issue that has been in my head for some time.
I'd like to know why Openwrt isn't using DSA instead of swconfig. I see that DSA is the chosen one upstream (linux kernel), and that this is disabled with a patch. I believe that I can revert this patch by myself, although I have few knowledge in these topics, so I'm here asking for help, opinions and hopefully to start a discusion about this!
Thanks!
My understanding regarding the road forward for DSA is that there is yet an acceptable methodology of migrating existing installs without breaking things.
The main reason for targets where DSA drivers are available and in a production ready state is the question of migrating existing configuration over a sysupgrade. This is an open question, as it's basically impossible to migrate even slightly modified switch configurations without effectively (soft-)bricking the device over an upgrade.
Another (relatively minor) issue is how to deal with multiple CPU ports within the DSA concept, for which no solution has been accepted in the mainline kernel yet (as I understand it, the upstream requirements for a potential implementation are still in a state of flux), but this is not the reason to avoid DSA (as you see, the turris omnia is already using DSA driver, actually it was considered to be a requirement to use DSA for merging support for it into OpenWrt - the situation is less clear for devices which were merged with swconfig defaults).
So let me see if I got this right... by default Openwrt doesn't use DSA because it could soft-brick routers over a sysupgrade?
I know that issue exists, been reading about it a lot and thinking about a solution myself, but still, right now, with the default configuration, if we switch to the DSA model with only one CPU port we don't really lose that much performance since the most used tasks preformed in these routers don't fully need the second port's performance. People usually forget that the CPU ports are full duplex and that they can do 1gbps one way and 1gbps another way.
Going back a bit to the DSA issue, I believe the solution lies in creating a team bonding interface with the existing CPU ports taking two ports and treat them logically as one, what do you think?
So, if I revert the patch that disables DSA and change the default uci config script I should get DSA enabled? If I make it do you think that maybe Openwrt will merge it to the trunk version?
My experience with DSA is that it isn’t ready for prime time yet. It doesn’t seem to properly handle VLANs yet, at least for the qca8k driver. The sheer number of patches being put forward on Linux-netdev is an indication of its immaturity at this point. Believe me, if it was functional I’d have brought up the IPQ4019-based EA8300 with it!
How long do you think It can take until It is ready?
User @neheb has a patch for DSA on Linksys devices, but I don't know if they still have it: Turris Omnia status
This patch made sure that DSA wouldn't be enabled for other devices for the introduction of the Turris Omnia (since it introduced an mvebu wide Kconfig that enabled DSA in the kernel), you could probably delete it. You will be affecting ALL mvebu boards though (not just Linksys devices).
You may or may not have to change this file, which handles the network interface assignment.
The Turris Omnia project folks have already started the transition of their mvebu boards to DSA with their OS4.X alphas. May have been this commit, but I am not sure.
As for my opinion, I don't think you would be able to upstream this to trunk. As @jeff said, it is still a moving target. But DSA has been with Marvell switches since Linux 2.6.28 (2008), so it may be a different situation for mvebu (but I haven't tested it myself). Furthermore, keep in mind you'd also need to change how LuCI works with configuring switches and VLANs.
@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.
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.
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:
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.