1. Apr 23, 2022
  2. Apr 22, 2022
  3. Apr 21, 2022
  4. Apr 20, 2022
    • Ido Schimmel's avatar
      selftests: mlxsw: vxlan_flooding_ipv6: Prevent flooding of unwanted packets · 5e624215
      Ido Schimmel authored
      The test verifies that packets are correctly flooded by the bridge and
      the VXLAN device by matching on the encapsulated packets at the other
      end. However, if packets other than those generated by the test also
      ingress the bridge (e.g., MLD packets), they will be flooded as well and
      interfere with the expected count.
      
      Make the test more robust by making sure that only the packets generated
      by the test can ingress the bridge. Drop all the rest using tc filters
      on the egress of 'br0' and 'h1'.
      
      In the software data path, the problem can be solved by matching on the
      inner destination MAC or dropping unwanted packets at the egress of the
      VXLAN device, but this is not currently supported by mlxsw.
      
      Fixes: d01724dd
      
       ("selftests: mlxsw: spectrum-2: Add a test for VxLAN flooding with IPv6")
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5e624215
    • Ido Schimmel's avatar
      selftests: mlxsw: vxlan_flooding: Prevent flooding of unwanted packets · 044011fd
      Ido Schimmel authored
      The test verifies that packets are correctly flooded by the bridge and
      the VXLAN device by matching on the encapsulated packets at the other
      end. However, if packets other than those generated by the test also
      ingress the bridge (e.g., MLD packets), they will be flooded as well and
      interfere with the expected count.
      
      Make the test more robust by making sure that only the packets generated
      by the test can ingress the bridge. Drop all the rest using tc filters
      on the egress of 'br0' and 'h1'.
      
      In the software data path, the problem can be solved by matching on the
      inner destination MAC or dropping unwanted packets at the egress of the
      VXLAN device, but this is not currently supported by mlxsw.
      
      Fixes: 94d302de
      
       ("selftests: mlxsw: Add a test for VxLAN flooding")
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      044011fd
    • David S. Miller's avatar
      Merge branch 'mlxsw-line-card-status-tracking' · 365014f5
      David S. Miller authored
      
      
      Ido Schimmel says:
      
      ====================
      mlxsw: Line cards status tracking
      
      When a line card is provisioned, netdevs corresponding to the ports
      found on the line card are registered. User space can then perform
      various logical configurations (e.g., splitting, setting MTU) on these
      netdevs.
      
      However, since the line card is not present / powered on (i.e., it is
      not in 'active' state), user space cannot access the various components
      found on the line card. For example, user space cannot read the
      temperature of gearboxes or transceiver modules found on the line card
      via hwmon / thermal. Similarly, it cannot dump the EEPROM contents of
      these transceiver modules. The above is only possible when the line card
      becomes active.
      
      This patchset solves the problem by tracking the status of each line
      card and invoking callbacks from interested parties when a line card
      becomes active / inactive.
      
      Patchset overview:
      
      Patch #1 adds the infrastructure in the line cards core that allows
      users to registers a set of callbacks that are invoked when a line card
      becomes active / inactive. To avoid races, if a line card is already
      active during registration, the got_active() callback is invoked.
      
      Patches #2-#3 are preparations.
      
      Patch #4 changes the port module core to register a set of callbacks
      with the line cards core. See detailed description with examples in the
      commit message.
      
      Patches #5-#6 do the same with regards to thermal / hwmon support, so
      that user space will be able to monitor the temperature of various
      components on the line card when it becomes active.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      365014f5