@jow suppose netifd is lacking something like option type 'dsa_bridge' to address DSA ports already bridged within the switch's fabric?
Creating a soft bridge does not only seem redundant and consuming unnecessarily CPU cycles for the kernel to handle traffic on the soft bridge but may cause issues with the DSA concept in general.
No, the DSA concept is about exposing the switch ports as netdevs to linux and allowing to configure the switching with standard commands.So by default there should be no switching between the ports and only by creating the bridge the driver should configure that.
Correct, it doesn't require the kernel to do that. The kernel bridge serves as configuration interface for the hardware switch.
No idea what you mean with that. If you want to have individual subnets / broadcast domains on each port, just configure them as independent interfaces.
Yes, because there must be only one interface per pool. If you want to treat multiple switch ports as one logical interface, you must bridge them with a Linux software bridge, there is no way around that.
I would not concur; maybe you just omitted the driver part though as in bridge driver because the soft bridge (device) does nothing about the configuration of the hardware switch but the bridge driver in conjunction with the switchdev framework.
Yes, that is what I meant and how I configured netifd in the meantime, except that the goal is not individual subnets but to have multiple DSA ports in the same subnet, just a bit more work to setup but saves the kernel soft bridge.
Thank you for the clarification.
Too bad, just a bit more work to setup the config then, I most certainly prefer to do away with the soft bridge and lets us disagree here as I am remaining of the opinion of it being unnecessary overhead with DSA ports on a managed switch.
In this documentation some common configuration scenarios are handled as showcases:
chosen for whatever use they had in mind but nothing set in stone to be followed by the letter. DHCP for the soft bridge is just a bit more convenient than configuring each DSA port separately, latter apparently my preference though.
what is your semantic of (different) subnet? In this case on IPv4 the Lan ports and clients connecting to the Lan ports are within the 192.168.84.0/24 mask, just need to be diligent with the pool range for each port (prevent clashing).
Having the same subnet range with different IPs on the various DSA ports might work - I didn't check myself how it behaves in practice, likely similar to having multiple IP addresses on a normal ethernet NIC. But I can't see how such a setup could work if you factor in WLAN. If you would set 192.168.84.*/24 on wlan0, routing will probably break down.
Furthermore it is not clear how dnsmasq reacts if multiple candidate interfaces are available to satisfy a given DHCP pool. Could be that it all works because it simply selects the first DSA port interface which then floods to all others, but that is all a lot of "ifs" and certainly not the way things are intended to work.
Also you're going to need a bridge anyway if you want a common broadcast domain for ethernet and wireless.
It also feels a bit odd that you're essentially adding N additional IP addresses plus ARP entries, associated source selection overhead etc. just to skip an unproven, claimed overhead of a software bridge.
I am totally fine if you implement your personal setups this way but since you open such a generic topic, then propose such a configuration deviating from the official DSA guidelines and marking your odd configuration as the solution, I am worried that you're setting a wrong and misleading precedent here.
Changed the solution, if you are more comfortable with it.
Asked as a question and had a discourse and you disagreed - suppose users reading through the thread will have more trust in you than me. You want me to put up an augmented in one particular post or the topic (if that is feasible)?
Did not test dnsmasq since not utilising it, odhcpd (as stated in the topic) is fine for me; might see how kea works out.
Not quite. Note how the DSA configuration example chooses adjacent, non-overlapping IP subnets while your config (at least judging from the screenshots) uses overlapping subnets (actually the same subnet on each port).