DSA Mini-tutorial still marked as Work In Progress

[Florian Fainelli]

On 9/7/2022 3:17 PM, David Lang wrote:
> 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?

DSA offloads the bridge to the switch hardware, so if the hardware 
switch can do its job and forward frames in hardware from port A to port 
B, it will do it. DSA has little significance here, the same constraints 
apply/applied to swconfig as well.

> 
> 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
>>
>>
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

-- 
Florian