I've read that DSA is the way forward, and that's left me a bit worried about upgrading in the future.
As an average user, I know how to assign vlans in a switchless x86-64 installation, as well as using vlans on the wireless routers to isolate ports, and that's been working well enough and flexible enough for me. I understand that vlan tagging can be a bit heavy on the CPU in many routers but I've no idea what problems the new DSA method is trying to solve.
This may be stupid but can anyone explain what DSA is and how it relates to switch and tagging?
It's a different way to accomplish basically the same. The main difference is that DSA has been accepted into the mainline kernel, while swconfig has not (and will not) been.
The configuration differs, both in terms of /etc/config/network syntax and how to deal with it on cli. DSA leverages iproute2/ bridge-utils and is integrated into the rest of the modern linux networking stack. Offloading (think about 48-port managed switches, as supported in the realtek target) happens transparently behind the curtain. Conceptionally, DSA exposes every port of a switch as its own interface (wan, lan1, lan2, …), which are then bridged together (transparently in hardware) as needed - VLAn tagging can be defined individually for each port.
For OpenWrt, DSA is still rather 'new' - and that's why there's still little experience with it and integration into netifd/ luci has been lacking before the first mainstream targets/ devices have been migrated over. This has now been resolved in master (and 21.02 will also get the missing luci changes soon, before its formal release). While there probably still room for future improvements, it's functional in its current state.
Thank you for the information.
So does that mean, with every port as its own interface, routers with ports connected via switch chip to the CPU, behaves more like switchless ports on the computers, so that we can just bridge or break them into bridges and .xxx vlans?
If that's the case, how does that affect performance? Because first it breaks up the ports that are actually connected through the switch to individual interfaces, that adds something into the process, but OTOH, should the native kernel support mitigate performance loss seen with the current swconfig method?
And lastly, swconfig shouldn't be able to work correctly on DSA firmwares,correct?
The magic happens behind the curtain, what can be offloaded in hardware, is done in hardware. Depending on the SOC design, some ports can be bridged in hardware (without CPU involvement --> generally the LAN ports), some are bridged in software (e.g. if you'd create a bridge over WAN and LAN).
Not really a difference compared to swconfig, just expressed differently.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.