Merge branch 'tag_8021q-cross-chip'
Vladimir Olteans says: ==================== Proper cross-chip support for tag_8021q The cross-chip bridging support for tag_8021q/sja1105 introduced here: https://patchwork.ozlabs.org/project/netdev/cover/20200510163743.18032-1-olteanv@gmail.com/ took some shortcuts and is not reusable in other topologies except for the one it was written for: disjoint DSA trees. A diagram of this topology can be seen here: https://patchwork.ozlabs.org/project/netdev/patch/20200510163743.18032-3-olteanv@gmail.com/ However there are sja1105 switches on other boards using other topologies, most notably: - Daisy chained: | sw0p0 sw0p1 sw0p2 sw0p3 sw0p4 [ user ] [ user ] [ user ] [ dsa ] [ cpu ] | +---------+ | sw1p0 sw1p1 sw1p2 sw1p3 sw1p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ] | +---------+ | sw2p0 sw2p1 sw2p2 sw2p3 sw2p4 [ user ] [ user ] [ user ] [ user ] [ dsa ] - "H" topology: eth0 eth1 | | CPU port CPU port | DSA link | sw0p0 sw0p1 sw0p2 sw0p3 sw0p4 -------- sw1p4 sw1p3 sw1p2 sw1p1 sw1p0 | | | | | | user user user user user user port port port port port port In fact, the current code for tag_8021q cross-chip links works for neither of these 2 classes of topologies. The main reasons are: (a) The sja1105 driver does not treat DSA links. In the "disjoint trees" topology, the routing port towards any other switch is also the CPU port, and that was already configured so it already worked. This series does not deal with enabling DSA links in the sja1105 driver, that is a fairly trivial task that will be dealt with separately. (b) The tag_8021q code for cross-chip links assumes that any 2 switches between cross-chip forwarding needs to be enabled (i.e. which have user ports part of the same bridge) are at most 1 hop away from each other. This was true for the "disjoint trees" case because once a packet reached the CPU port, VLAN-unaware bridging was done by the DSA master towards the other switches based on destination MAC address, so the tag_8021q header was not interpreted in any way. However, in a daisy chain setup with 3 switches, all of them will interpret the tag_8021q header, and all tag_8021q VLANs need to be installed in all switches. When looking at the O(n^2) real complexity of the problem, it is clear that the current code had absolutely no chance of working in the general case. So this patch series brings a redesign of tag_8021q, in light of its new requirements. Anything with O(n^2) complexity (where n is the number of switches in a DSA tree) is an obvious candidate for the DSA cross-chip notifier support. One by one, the patches are: - The sja1105 driver is extremely entangled with tag_8021q, to be exact, with that driver's best_effort_vlan_filtering support. We drop this operating mode, which means that sja1105 temporarily loses network stack termination for VLAN-aware bridges. That operating mode raced itself to its own grave anyway due to some hardware limitations in combination with PTP reported by NXP customers. I can't say a lot more, but network stack termination for VLAN-aware bridges in sja1105 will be reimplemented soon with a much, much better solution. - What remains of tag_8021q in sja1105 is support for standalone ports mode and for VLAN-unaware bridging. We refactor the API surface of tag_8021q to a single pair of dsa_tag_8021q_{register,unregister} functions and we clean up everything else related to tag_8021q from sja1105 and felix. - Then we move tag_8021q into the DSA core. I thought about this a lot, and there is really no other way to add a DSA_NOTIFIER_TAG_8021Q_VLAN_ADD cross-chip notifier if DSA has no way to know if the individual switches use tag_8021q or not. So it needs to be part of the core to use notifiers. - Then we modify tag_8021q to update dynamically on bridge_{join,leave} events, instead of what we have today which is simply installing the VLANs on all ports of a switch and leaving port isolation up to somebody else. This change is necessary because port isolation over a DSA link cannot be done in any other way except based on VLAN membership, as opposed to bridging within the same switch which had 2 choices (at least on sja1105). - Finally we add 2 new cross-chip notifiers for adding and deleting a tag_8021q VLAN, which is properly refcounted similar to the bridge FDB and MDB code, and complete cleanup is done on teardown (note that this is unlike regular bridge VLANs, where we currently cannot do refcounting because the user can run "bridge vlan add dev swp0 vid 100" a gazillion times, and "bridge vlan del dev swp0 vid 100" just once, and for some reason expect that the VLAN will be deleted. But I digress). With this opportunity we remove a lot of hard-to-digest code and replace it with much more idiomatic DSA-style code. This series was regression-tested on: - Single-switch boards with SJA1105T - Disjoint-tree boards with SJA1105S and Felix (using ocelot-8021q) - H topology boards using SJA1110A ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
Showing
Please register or sign in to comment