Re: DSA Mini-tutorial still marked as Work In Progress
On Fri, 9 Sep 2022, Michael Richardson wrote: Jo-Philipp Wich wrote: > 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. .. > 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... +1 One thing that we do need to show is what ethernet devices are on the switch, there is a considerable CPU load to routing traffic through the processor vs through the switch, so when people are deciding what ports to use for different purposes, they need to easily be able to see this info. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
Jo-Philipp Wich wrote: > 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. .. > 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... +1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
Hey Luiz, On 8.09.2022 06:28, Luiz Angelo Daros de Luca wrote: - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" - VLAN filtering disabled Bridging virtual 802.1q interfaces might fail in some scenarios, like when you use vlan1 or mix tagged with untagged traffic (https://github.com/openwrt/openwrt/issues/9066) I do recommend bridge-vlan as the first option, although ip-bridge is not installed by default. I know that it is a little bit off topic but I would love some transitioning code that could mimic swconfig devices as if they were DSA. Instead of using swconfig settings for tagged vlans/isolated ports, just create fake lan1, lan2, wan interfaces (802.1q) and derive the swconfig settings from that. I've been doing that for some time, creating switch_vlan configs from bridge+bridge-vlan and replacing the user ports with the CPU port in every related bridge-vlan. This way I can share the config with swconfig, DSA and even devices without switches (VM like gns3) if I rename eth0, eth1, eth2 to lan1, wan, lan2. The only downsides are that untagged bridging is done using software bridge and the config is generated as a single-shot step (uci-default). However, if that mapping is done inside netifd, I believe it might be able to better handle those cases. I tried this two months ago, here are the steps I took to be precise: ## Set up the Interfaces - Put each port on a different VLAN as untagged, set the CPU port tagged. - Rename ethX.y to the switch port name you want (optional). - There’s currently no way. So just ignore ethX.y interfaces and manually create VLAN interfaces of ethX with the interface name mimicking DSA. - Put the manually created interfaces on a VLAN filtering enabled bridge. ## Untagged - Set a VLAN ID as untagged on the manually created interfaces. - Configure LAN with that VLAN interface of the bridge to be able to reach the router from the switch ports. This works great until tagged frames are involved: ## Tagged - Set a VLAN ID as tagged for a manually created interface. - Create a new network with that VLAN interface of the bridge. Set IP to 192.168.1.1/24 and use a firewall zone with everything allowed. - Set that VLAN ID on the computer and set IP to 192.168.1.2/24. - Ping 192.168.1.2 from the router. - See if tagged frames pass the switch port with the bridge VLAN filtering feature. - Tagged frames leave the switch port. However, tagged frames coming in will be dropped since the port was configured to only allow untagged frames. If someone is confused like I was before, swconfig’s VLAN filtering won’t interfere with bridge VLAN filtering because they are separate systems. With these findings, there are two changes I can see being made to swconfig: - Allow custom names for the VLAN interface of the CPU port. - Allow forwarding tagged frames to the CPU port coming from a switch port set as untagged. Nonetheless, this is extremely hacky so I just put this out here for some fun talk. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
On 8.09.2022 02:54, Florian Fainelli wrote: On 9/7/2022 3:00 PM, Sebastian Moeller wrote: Hi Jo, I was under the impression* that bridge-vlan filtering is something that can be relegated to the switch hardware, while creating a bridge between VLAN interfaces happens in software. Is that wrong? It is incorrect. DSA offloads the bridge to the switch hardware whether you have VLAN filtering or not. When the bridge is not VLAN aware (vlan_filtering=0) what it means is that the Linux bridge, and the underlying switch MUST accept both VLAN and non-VLAN tagged frames. If you do want VLAN tagged frames in that bridge, then you are supposed to terminate VLAN traffic by creating upper VLAN devices such as lan1.10, lan2.10 etc. but the switching between lan1.10 and lan2.10 still happens in hardware because those VLAN devices are offloaded into the switch hardware. When vlan_filtering=1 is set, the hardware is configured to only accept untagged PVID frames as well as whichever VLAN tagged frames you have configured. For instance, if you configured your bridge this way with: lan1, lan2, lan3 and lan4 part of br-lan with vlan_filtering=1, each switch port will be programmed to be in the bridge's default_pvid (1, unless changed), and if you sent a VLAN tagged frame with VLAN ID 2 towards any of those ports, and assuming the switch hardware is capable of it, that VLAN ID 2 frame creates an egress VID violation and is discarded. If not discarded in hardware it would be discarded in software. I've made a detailed write up of this here: https://openwrt.org/playground/arinc9/bridge-vlan-filtering#egress_untagged_egress_tagged_and_pvid Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
> - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" > - VLAN filtering disabled Bridging virtual 802.1q interfaces might fail in some scenarios, like when you use vlan1 or mix tagged with untagged traffic (https://github.com/openwrt/openwrt/issues/9066) I do recommend bridge-vlan as the first option, although ip-bridge is not installed by default. I know that it is a little bit off topic but I would love some transitioning code that could mimic swconfig devices as if they were DSA. Instead of using swconfig settings for tagged vlans/isolated ports, just create fake lan1, lan2, wan interfaces (802.1q) and derive the swconfig settings from that. I've been doing that for some time, creating switch_vlan configs from bridge+bridge-vlan and replacing the user ports with the CPU port in every related bridge-vlan. This way I can share the config with swconfig, DSA and even devices without switches (VM like gns3) if I rename eth0, eth1, eth2 to lan1, wan, lan2. The only downsides are that untagged bridging is done using software bridge and the config is generated as a single-shot step (uci-default). However, if that mapping is done inside netifd, I believe it might be able to better handle those cases. Regards, Luiz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
On 9/7/2022 3:00 PM, Sebastian Moeller wrote: Hi Jo, I was under the impression* that bridge-vlan filtering is something that can be relegated to the switch hardware, while creating a bridge between VLAN interfaces happens in software. Is that wrong? It is incorrect. DSA offloads the bridge to the switch hardware whether you have VLAN filtering or not. When the bridge is not VLAN aware (vlan_filtering=0) what it means is that the Linux bridge, and the underlying switch MUST accept both VLAN and non-VLAN tagged frames. If you do want VLAN tagged frames in that bridge, then you are supposed to terminate VLAN traffic by creating upper VLAN devices such as lan1.10, lan2.10 etc. but the switching between lan1.10 and lan2.10 still happens in hardware because those VLAN devices are offloaded into the switch hardware. When vlan_filtering=1 is set, the hardware is configured to only accept untagged PVID frames as well as whichever VLAN tagged frames you have configured. For instance, if you configured your bridge this way with: lan1, lan2, lan3 and lan4 part of br-lan with vlan_filtering=1, each switch port will be programmed to be in the bridge's default_pvid (1, unless changed), and if you sent a VLAN tagged frame with VLAN ID 2 towards any of those ports, and assuming the switch hardware is capable of it, that VLAN ID 2 frame creates an egress VID violation and is discarded. If not discarded in hardware it would be discarded in software. Hope this helps. Regards Sebastian *) Not sure where I got that impression from On Sep 7, 2022, at 23:48, 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@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org
Re: DSA Mini-tutorial still marked as Work In Progress
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@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
Hi Jo, I was under the impression* that bridge-vlan filtering is something that can be relegated to the switch hardware, while creating a bridge between VLAN interfaces happens in software. Is that wrong? Regards Sebastian *) Not sure where I got that impression from > On Sep 7, 2022, at 23:48, 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@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
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 signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
On 07/09/2022 00:33, Florian Fainelli wrote: On 9/4/2022 2:32 PM, Arınç ÜNAL wrote: Hi Rich, On 4.09.2022 17:58, Rich Brown wrote: Folks, The DSA Mini-tutorial on the Wiki (https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial) is still marked as a "Work In Progress" I should know - I wrote this up as we were getting ready to ship 21.02, and I thought that we should have something about DSA on the wiki. But I don't really know anything about DSA - I simply pieced the article together from a few forum posts. And I never received any direct feedback or saw any updates to the wiki page. I was "makin' a lot of stuff up" as I wrote that page. It's the best I could do, but nothing that's written there should be taken as gospel. The italics near the top indicate areas of uncertainty. I also was guessing about the difference between device and interface definitions. Here's my request: It would do my heart good to have someone who's knowledgeable about DSA read through the page and either make direct corrections, or send me a note and I'll make them. Thanks. I don't see much content to document DSA. All DSA does is creating a network interface for each switch port. What I think should be properly documented is the Bridge VLAN filtering feature. I have made some efforts to do that on my playground here: https://openwrt.org/playground/arinc9/start I know I was supposed to deliver much more, much earlier. I still have a huge list of things to do on LuCI, UCI and OpenWrt Wiki, forcefully pushed down to the bottom of my task list. Maybe this is enough to reference since it contains basic use cases, and not so basic ones, too: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/dsa/configuration.rst This is great. Though, I'd rather link it from somewhere that can make use of the reStructuredText file, like GitHub. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
On 9/4/2022 2:32 PM, Arınç ÜNAL wrote: Hi Rich, On 4.09.2022 17:58, Rich Brown wrote: Folks, The DSA Mini-tutorial on the Wiki (https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial) is still marked as a "Work In Progress" I should know - I wrote this up as we were getting ready to ship 21.02, and I thought that we should have something about DSA on the wiki. But I don't really know anything about DSA - I simply pieced the article together from a few forum posts. And I never received any direct feedback or saw any updates to the wiki page. I was "makin' a lot of stuff up" as I wrote that page. It's the best I could do, but nothing that's written there should be taken as gospel. The italics near the top indicate areas of uncertainty. I also was guessing about the difference between device and interface definitions. Here's my request: It would do my heart good to have someone who's knowledgeable about DSA read through the page and either make direct corrections, or send me a note and I'll make them. Thanks. I don't see much content to document DSA. All DSA does is creating a network interface for each switch port. What I think should be properly documented is the Bridge VLAN filtering feature. I have made some efforts to do that on my playground here: https://openwrt.org/playground/arinc9/start I know I was supposed to deliver much more, much earlier. I still have a huge list of things to do on LuCI, UCI and OpenWrt Wiki, forcefully pushed down to the bottom of my task list. Maybe this is enough to reference since it contains basic use cases, and not so basic ones, too: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/dsa/configuration.rst -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
Hi Rich, On 4.09.2022 17:58, Rich Brown wrote: Folks, The DSA Mini-tutorial on the Wiki (https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial) is still marked as a "Work In Progress" I should know - I wrote this up as we were getting ready to ship 21.02, and I thought that we should have something about DSA on the wiki. But I don't really know anything about DSA - I simply pieced the article together from a few forum posts. And I never received any direct feedback or saw any updates to the wiki page. I was "makin' a lot of stuff up" as I wrote that page. It's the best I could do, but nothing that's written there should be taken as gospel. The italics near the top indicate areas of uncertainty. I also was guessing about the difference between device and interface definitions. Here's my request: It would do my heart good to have someone who's knowledgeable about DSA read through the page and either make direct corrections, or send me a note and I'll make them. Thanks. I don't see much content to document DSA. All DSA does is creating a network interface for each switch port. What I think should be properly documented is the Bridge VLAN filtering feature. I have made some efforts to do that on my playground here: https://openwrt.org/playground/arinc9/start I know I was supposed to deliver much more, much earlier. I still have a huge list of things to do on LuCI, UCI and OpenWrt Wiki, forcefully pushed down to the bottom of my task list. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
DSA Mini-tutorial still marked as Work In Progress
Folks, The DSA Mini-tutorial on the Wiki (https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial) is still marked as a "Work In Progress" I should know - I wrote this up as we were getting ready to ship 21.02, and I thought that we should have something about DSA on the wiki. But I don't really know anything about DSA - I simply pieced the article together from a few forum posts. And I never received any direct feedback or saw any updates to the wiki page. I was "makin' a lot of stuff up" as I wrote that page. It's the best I could do, but nothing that's written there should be taken as gospel. The italics near the top indicate areas of uncertainty. I also was guessing about the difference between device and interface definitions. Here's my request: It would do my heart good to have someone who's knowledgeable about DSA read through the page and either make direct corrections, or send me a note and I'll make them. Thanks. Rich ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
