DSA Mini-tutorial still marked as Work In Progress

[David Lang]

with DSA, do you HAVE to go through the cpu interface and kernel to bridge 
different ports on the switch? or can you still do vlan routing inside the 
switch?

for the Scale conference, I've done a lot of work using the switch for passing 
vlan tagged traffic on to other systems while only sending some of it to the CPU 
(the CPU would be a very significant bottleneck if I tried to send everything 
though it)

David Lang

On Wed, 7 Sep 2022, Jo-Philipp Wich wrote:

> Hi Rich,
>
> that tutorial is good ground work imho. One thing I repeatedly noticed (not in
> the document, but in forum and irc chatter) is that over the time, DSA and
> bridge VLAN filtering became conflated into one concept while they're actually
> different pieces; one can do bridge VLAN filtering without DSA and one can
> utilize DSA without doing bridge VLAN filtering.
>
> Bluntly speaking, DSA is the thing that gives you one Linux network device per
> switch port and bridge VLAN filtering is the stuff that allows you declaring
> swconfig-esque VLAN port groups on top of an arbitrary bridge interface.
>
> I think this is something we should try to better convey in the documentation.
>
> For example simple common use cases like:
>
> - Making each switch port it's own independent interface with own subnet
>
> or
>
> - Break out one switch port to turn it into some kind of restricted IoT or
>   guest network access port
>
> or
>
> - Bridge each ethernet port to another SSID
>
> don't require bridge VLAN filtering or touching VLANs in general at all (in
> contrast to former swconfig). The per-port net devices just have to be taken
> out of the br-lan bridge and either be put into another bridge or configured
> as independent network devices.
>
> Bridge VLAN filtering on the other hand is only actually needed if you want to
> deal with VLAN tagged traffic inside the bridge. And even then there's
> sometimes alternative ways, for example the following two scenarios should be
> functionally equivalent:
>
> - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10"
>  - VLAN filtering disabled
>
> vs.
>
> - Bridge device "br-lan" containing "lan1 lan2 lan3"
>  - VLAN filtering enabled
>  - Bridge VLAN #10 containing lan1 as tagged, lan2 as tagged, lan3 as tagged
> - VLAN device br-lan.10 on top of br-lan
>
>
> In the former case you would put your IP address settings onto the dedicated
> "br-vlan10" bridge device while in the latter case you would configure the IP
> addressing on the "br-lan.10" subinterface of the "br-lan" bridge.
>
> So maybe it makes sense to focus on the "with DSA, your switch just becomes a
> linux bridge over a bunch of netdevs" aspect in the mini tutorial and break
> out any bridge-VLAN related information into a separate advanced VLAN tutorial.
>
> Another conceptual issue I see is that people came to expect a dedicated
> "switch" configuration ui which is something that does not really work with
> DSA devices anymore since there is no dedicated switch hardware entity to
> interact with anymore (DSA takes care of completely abstracting this away from
> the user point of view) and that bridge-vlans just happen to be a
> configuration detail of a bridge, and that there happens to be a bridge
> "br-lan" by default, but a system could have multiple bridges, or none at all.
>
> So we should also explain why there is no central "switch configuration"
> anymore and that this does not translate into a loss of functionality, but
> that the former semi opague swconfig switch configuration entity was dissolved
> into a bunch of ethernet devices inside a bridge...
>
>
>
> ~ Jo
>
>