1. 18 Mar, 2022 24 commits
  2. 17 Mar, 2022 16 commits
    • Jakub Kicinski's avatar
      Merge branch 'net-bridge-multiple-spanning-trees' · 82e94d41
      Jakub Kicinski authored
      Tobias Waldekranz says:
      
      ====================
      net: bridge: Multiple Spanning Trees
      
      The bridge has had per-VLAN STP support for a while now, since:
      
      https://lore.kernel.org/netdev/20200124114022.10883-1-nikolay@cumulusnetworks.com/
      
      The current implementation has some problems:
      
      - The mapping from VLAN to STP state is fixed as 1:1, i.e. each VLAN
        is managed independently. This is awkward from an MSTP (802.1Q-2018,
        Clause 13.5) point of view, where the model is that multiple VLANs
        are grouped into MST instances.
      
        Because of the way that the standard is written, presumably, this is
        also reflected in hardware implementations. It is not uncommon for a
        switch to support the full 4k range of VIDs, but that the pool of
        MST instances is much smaller. Some examples:
      
        Marvell LinkStreet (mv88e6xxx): 4k VLANs, but only 64 MSTIs
        Marvell Prestera: 4k VLANs, but only 128 MSTIs
        Microchip SparX-5i: 4k VLANs, but only 128 MSTIs
      
      - By default, the feature is enabled, and there is no way to disable
        it. This makes it hard to add offloading in a backwards compatible
        way, since any underlying switchdevs have no way to refuse the
        function if the hardware does not support it
      
      - The port-global STP state has precedence over per-VLAN states. In
        MSTP, as far as I understand it, all VLANs will use the common
        spanning tree (CST) by default - through traffic engineering you can
        then optimize your network to group subsets of VLANs to use
        different trees (MSTI). To my understanding, the way this is
        typically managed in silicon is roughly:
      
        Incoming packet:
        .----.----.--------------.----.-------------
        | DA | SA | 802.1Q VID=X | ET | Payload ...
        '----'----'--------------'----'-------------
                              |
                              '->|\     .----------------------------.
                                 | +--> | VID | Members | ... | MSTI |
                         PVID -->|/     |-----|---------|-----|------|
                                        |   1 | 0001001 | ... |    0 |
                                        |   2 | 0001010 | ... |   10 |
                                        |   3 | 0001100 | ... |   10 |
                                        '----------------------------'
                                                                   |
                                     .-----------------------------'
                                     |  .------------------------.
                                     '->| MSTI | Fwding | Lrning |
                                        |------|--------|--------|
                                        |    0 | 111110 | 111110 |
                                        |   10 | 110111 | 110111 |
                                        '------------------------'
      
        What this is trying to show is that the STP state (whether MSTP is
        used, or ye olde STP) is always accessed via the VLAN table. If STP
        is running, all MSTI pointers in that table will reference the same
        index in the STP stable - if MSTP is running, some VLANs may point
        to other trees (like in this example).
      
        The fact that in the Linux bridge, the global state (think: index 0
        in most hardware implementations) is supposed to override the
        per-VLAN state, is very awkward to offload. In effect, this means
        that when the global state changes to blocking, drivers will have to
        iterate over all MSTIs in use, and alter them all to match. This
        also means that you have to cache whether the hardware state is
        currently tracking the global state or the per-VLAN state. In the
        first case, you also have to cache the per-VLAN state so that you
        can restore it if the global state transitions back to forwarding.
      
      This series adds a new mst_enable bridge setting (as suggested by Nik)
      that can only be changed when no VLANs are configured on the
      bridge. Enabling this mode has the following effect:
      
      - The port-global STP state is used to represent the CST (Common
        Spanning Tree) (1/15)
      
      - Ingress STP filtering is deferred until the frame's VLAN has been
        resolved (1/15)
      
      - The preexisting per-VLAN states can no longer be controlled directly
        (1/15). They are instead placed under the MST module's control,
        which is managed using a new netlink interface (described in 3/15)
      
      - VLANs can br mapped to MSTIs in an arbitrary M:N fashion, using a
        new global VLAN option (2/15)
      
      Switchdev notifications are added so that a driver can track:
      - MST enabled state
      - VID to MSTI mappings
      - MST port states
      
      An offloading implementation is this provided for mv88e6xxx.
      ====================
      
      Link: https://lore.kernel.org/r/20220316150857.2442916-1-tobias@waldekranz.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      82e94d41
    • Tobias Waldekranz's avatar
      net: dsa: mv88e6xxx: MST Offloading · acaf4d2e
      Tobias Waldekranz authored
      Allocate a SID in the STU for each MSTID in use by a bridge and handle
      the mapping of MSTIDs to VLANs using the SID field of each VTU entry.
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      acaf4d2e
    • Tobias Waldekranz's avatar
      net: dsa: mv88e6xxx: Export STU as devlink region · 7dc96039
      Tobias Waldekranz authored
      Export the raw STU data in a devlink region so that it can be
      inspected from userspace and compared to the current bridge
      configuration.
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      7dc96039
    • Tobias Waldekranz's avatar
      net: dsa: mv88e6xxx: Disentangle STU from VTU · 49c98c1d
      Tobias Waldekranz authored
      In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states
      were kept in the VTU - there was no concept of a SID. Later, the
      information was split into two tables, where the VTU only tracked
      memberships and deferred the STP state tracking to the STU via a
      pointer (SID). This meant that a group of VLANs could share the same
      STU entry. Most likely, this was done to align with MSTP (802.1Q-2018,
      Clause 13), which is built on this principle.
      
      While the VTU is still 4k lines on most devices, the STU is capped at
      64 entries. This means that the current stategy, updating STU info
      whenever a VTU entry is updated, can not easily support MSTP because:
      
      - The maximum number of VIDs would also be capped at 64, as we would
        have to allocate one SID for every VTU entry - even if many VLANs
        would effectively share the same MST.
      
      - MSTP updates would be unnecessarily slow as you would have to
        iterate over all VLANs that share the same MST.
      
      In order to support MSTP offloading in the future, manage the STU as a
      separate entity from the VTU.
      
      Only add support for newer hardware with separate VTU and
      STU. VTU-only devices can also be supported, but essentially this
      requires a software implementation of an STU (fanning out state
      changed to all VLANs tied to the same MST).
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      49c98c1d
    • Tobias Waldekranz's avatar
      net: dsa: Handle MST state changes · 7414af30
      Tobias Waldekranz authored
      Add the usual trampoline functionality from the generic DSA layer down
      to the drivers for MST state changes.
      
      When a state changes to disabled/blocking/listening, make sure to fast
      age any dynamic entries in the affected VLANs (those controlled by the
      MSTI in question).
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      7414af30
    • Tobias Waldekranz's avatar
      net: dsa: Pass VLAN MSTI migration notifications to driver · 8e6598a7
      Tobias Waldekranz authored
      Add the usual trampoline functionality from the generic DSA layer down
      to the drivers for VLAN MSTI migrations.
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8e6598a7
    • Tobias Waldekranz's avatar
      net: dsa: Validate hardware support for MST · 332afc4c
      Tobias Waldekranz authored
      When joining a bridge where MST is enabled, we validate that the
      proper offloading support is in place, otherwise we fallback to
      software bridging.
      
      When then mode is changed on a bridge in which we are members, we
      refuse the change if offloading is not supported.
      
      At the moment we only check for configurable learning, but this will
      be further restricted as we support more MST related switchdev events.
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      332afc4c
    • Tobias Waldekranz's avatar
      net: bridge: mst: Add helper to query a port's MST state · f54fd0e1
      Tobias Waldekranz authored
      This is useful for switchdev drivers who are offloading MST states
      into hardware. As an example, a driver may wish to flush the FDB for a
      port when it transitions from forwarding to blocking - which means
      that the previous state must be discoverable.
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Acked-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f54fd0e1
    • Tobias Waldekranz's avatar
      net: bridge: mst: Add helper to check if MST is enabled · 48d57b2e
      Tobias Waldekranz authored
      This is useful for switchdev drivers that might want to refuse to join
      a bridge where MST is enabled, if the hardware can't support it.
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Acked-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      48d57b2e
    • Tobias Waldekranz's avatar
      net: bridge: mst: Add helper to map an MSTI to a VID set · cceac97a
      Tobias Waldekranz authored
      br_mst_get_info answers the question: "On this bridge, which VIDs are
      mapped to the given MSTI?"
      
      This is useful in switchdev drivers, which might have to fan-out
      operations, relating to an MSTI, per VLAN.
      
      An example: When a port's MST state changes from forwarding to
      blocking, a driver may choose to flush the dynamic FDB entries on that
      port to get faster reconvergence of the network, but this should only
      be done in the VLANs that are managed by the MSTI in question.
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Acked-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      cceac97a
    • Tobias Waldekranz's avatar
      net: bridge: mst: Notify switchdev drivers of MST state changes · 7ae9147f
      Tobias Waldekranz authored
      Generate a switchdev notification whenever an MST state changes. This
      notification is keyed by the VLANs MSTI rather than the VID, since
      multiple VLANs may share the same MST instance.
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Acked-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      7ae9147f
    • Tobias Waldekranz's avatar
      net: bridge: mst: Notify switchdev drivers of VLAN MSTI migrations · 6284c723
      Tobias Waldekranz authored
      Whenever a VLAN moves to a new MSTI, send a switchdev notification so
      that switchdevs can track a bridge's VID to MSTI mappings.
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Acked-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6284c723
    • Tobias Waldekranz's avatar
      net: bridge: mst: Notify switchdev drivers of MST mode changes · 87c167bb
      Tobias Waldekranz authored
      Trigger a switchdev event whenever the bridge's MST mode is
      enabled/disabled. This allows constituent ports to either perform any
      required hardware config, or refuse the change if it not supported.
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Acked-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      87c167bb
    • Tobias Waldekranz's avatar
      net: bridge: mst: Support setting and reporting MST port states · 122c2948
      Tobias Waldekranz authored
      Make it possible to change the port state in a given MSTI by extending
      the bridge port netlink interface (RTM_SETLINK on PF_BRIDGE).The
      proposed iproute2 interface would be:
      
          bridge mst set dev <PORT> msti <MSTI> state <STATE>
      
      Current states in all applicable MSTIs can also be dumped via a
      corresponding RTM_GETLINK. The proposed iproute interface looks like
      this:
      
      $ bridge mst
      port              msti
      vb1               0
      		    state forwarding
      		  100
      		    state disabled
      vb2               0
      		    state forwarding
      		  100
      		    state forwarding
      
      The preexisting per-VLAN states are still valid in the MST
      mode (although they are read-only), and can be queried as usual if one
      is interested in knowing a particular VLAN's state without having to
      care about the VID to MSTI mapping (in this example VLAN 20 and 30 are
      bound to MSTI 100):
      
      $ bridge -d vlan
      port              vlan-id
      vb1               10
      		    state forwarding mcast_router 1
      		  20
      		    state disabled mcast_router 1
      		  30
      		    state disabled mcast_router 1
      		  40
      		    state forwarding mcast_router 1
      vb2               10
      		    state forwarding mcast_router 1
      		  20
      		    state forwarding mcast_router 1
      		  30
      		    state forwarding mcast_router 1
      		  40
      		    state forwarding mcast_router 1
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Acked-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      122c2948
    • Tobias Waldekranz's avatar
      net: bridge: mst: Allow changing a VLAN's MSTI · 8c678d60
      Tobias Waldekranz authored
      Allow a VLAN to move out of the CST (MSTI 0), to an independent tree.
      
      The user manages the VID to MSTI mappings via a global VLAN
      setting. The proposed iproute2 interface would be:
      
          bridge vlan global set dev br0 vid <VID> msti <MSTI>
      
      Changing the state in non-zero MSTIs is still not supported, but will
      be addressed in upcoming changes.
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Acked-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8c678d60
    • Tobias Waldekranz's avatar
      net: bridge: mst: Multiple Spanning Tree (MST) mode · ec7328b5
      Tobias Waldekranz authored
      Allow the user to switch from the current per-VLAN STP mode to an MST
      mode.
      
      Up to this point, per-VLAN STP states where always isolated from each
      other. This is in contrast to the MSTP standard (802.1Q-2018, Clause
      13.5), where VLANs are grouped into MST instances (MSTIs), and the
      state is managed on a per-MSTI level, rather that at the per-VLAN
      level.
      
      Perhaps due to the prevalence of the standard, many switching ASICs
      are built after the same model. Therefore, add a corresponding MST
      mode to the bridge, which we can later add offloading support for in a
      straight-forward way.
      
      For now, all VLANs are fixed to MSTI 0, also called the Common
      Spanning Tree (CST). That is, all VLANs will follow the port-global
      state.
      
      Upcoming changes will make this actually useful by allowing VLANs to
      be mapped to arbitrary MSTIs and allow individual MSTI states to be
      changed.
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Acked-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ec7328b5