• DENG Qingfang's avatar
    net: dsa: mt7530: use independent VLAN learning on VLAN-unaware bridges · 6087175b
    DENG Qingfang authored
    Consider the following bridge configuration, where bond0 is not
    offloaded:
    
             +-- br0 --+
            / /   |     \
           / /    |      \
          /  |    |     bond0
         /   |    |     /   \
       swp0 swp1 swp2 swp3 swp4
         .        .       .
         .        .       .
         A        B       C
    
    Ideally, when the switch receives a packet from swp3 or swp4, it should
    forward the packet to the CPU, according to the port matrix and unknown
    unicast flood settings.
    
    But packet loss will happen if the destination address is at one of the
    offloaded ports (swp0~2). For example, when client C sends a packet to
    A, the FDB lookup will indicate that it should be forwarded to swp0, but
    the port matrix of swp3 and swp4 is configured to only allow the CPU to
    be its destination, so it is dropped.
    
    However, this issue does not happen if the bridge is VLAN-aware. That is
    because VLAN-aware bridges use independent VLAN learning, i.e. use VID
    for FDB lookup, on offloaded ports. As swp3 and swp4 are not offloaded,
    shared VLAN learning with default filter ID of 0 is used instead. So the
    lookup for A with filter ID 0 never hits and the packet can be forwarded
    to the CPU.
    
    In the current code, only two combinations were used to toggle user
    ports' VLAN awareness: one is PCR.PORT_VLAN set to port matrix mode with
    PVC.VLAN_ATTR set to transparent port, the other is PCR.PORT_VLAN set to
    security mode with PVC.VLAN_ATTR set to user port.
    
    It turns out that only PVC.VLAN_ATTR contributes to VLAN awareness, and
    port matrix mode just skips the VLAN table lookup. The reference manual
    is somehow misleading when describing PORT_VLAN modes. It states that
    PORT_MEM (VLAN port member) is used for destination if the VLAN table
    lookup hits, but actually **PORT_MEM & PORT_MATRIX** (bitwise AND of
    VLAN port member and port matrix) is used instead, which means we can
    have two or more separate VLAN-aware bridges with the same PVID and
    traffic won't leak between them.
    
    Therefore, to solve this, enable independent VLAN learning with PVID 0
    on VLAN-unaware bridges, by setting their PCR.PORT_VLAN to fallback
    mode, while leaving standalone ports in port matrix mode. The CPU port
    is always set to fallback mode to serve those bridges.
    
    During testing, it is found that FDB lookup with filter ID of 0 will
    also hit entries with VID 0 even with independent VLAN learning. To
    avoid that, install all VLANs with filter ID of 1.
    Signed-off-by: default avatarDENG Qingfang <dqfext@gmail.com>
    Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    6087175b
mt7530.c 81.7 KB