• Vladimir Oltean's avatar
    net: dsa: add explicit support for host bridge VLANs · 134ef238
    Vladimir Oltean authored
    Currently, DSA programs VLANs on shared (DSA and CPU) ports each time it
    does so on user ports. This is good for basic functionality but has
    several limitations:
    
    - the VLAN group which must reach the CPU may be radically different
      from the VLAN group that must be autonomously forwarded by the switch.
      In other words, the admin may want to isolate noisy stations and avoid
      traffic from them going to the control processor of the switch, where
      it would just waste useless cycles. The bridge already supports
      independent control of VLAN groups on bridge ports and on the bridge
      itself, and when VLAN-aware, it will drop packets in software anyway
      if their VID isn't added as a 'self' entry towards the bridge device.
    
    - Replaying host FDB entries may depend, for some drivers like mv88e6xxx,
      on replaying the host VLANs as well. The 2 VLAN groups are
      approximately the same in most regular cases, but there are corner
      cases when timing matters, and DSA's approximation of replicating
      VLANs on shared ports simply does not work.
    
    - If a user makes the bridge (implicitly the CPU port) join a VLAN by
      accident, there is no way for the CPU port to isolate itself from that
      noisy VLAN except by rebooting the system. This is because for each
      VLAN added on a user port, DSA will add it on shared ports too, but
      for each VLAN deletion on a user port, it will remain installed on
      shared ports, since DSA has no good indication of whether the VLAN is
      still in use or not.
    
    Now that the bridge driver emits well-balanced SWITCHDEV_OBJ_ID_PORT_VLAN
    addition and removal events, DSA has a simple and straightforward task
    of separating the bridge port VLANs (these have an orig_dev which is a
    DSA slave interface, or a LAG interface) from the host VLANs (these have
    an orig_dev which is a bridge interface), and to keep a simple reference
    count of each VID on each shared port.
    
    Forwarding VLANs must be installed on the bridge ports and on all DSA
    ports interconnecting them. We don't have a good view of the exact
    topology, so we simply install forwarding VLANs on all DSA ports, which
    is what has been done until now.
    
    Host VLANs must be installed primarily on the dedicated CPU port of each
    bridge port. More subtly, they must also be installed on upstream-facing
    and downstream-facing DSA ports that are connecting the bridge ports and
    the CPU. This ensures that the mv88e6xxx's problem (VID of host FDB
    entry may be absent from VTU) is still addressed even if that switch is
    in a cross-chip setup, and it has no local CPU port.
    
    Therefore:
    - user ports contain only bridge port (forwarding) VLANs, and no
      refcounting is necessary
    - DSA ports contain both forwarding and host VLANs. Refcounting is
      necessary among these 2 types.
    - CPU ports contain only host VLANs. Refcounting is also necessary.
    Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    134ef238
port.c 33.4 KB