1. 28 7月, 2019 2 次提交
  2. 26 7月, 2019 2 次提交
  3. 20 7月, 2019 3 次提交
  4. 18 7月, 2019 2 次提交
    • I
      mlxsw: spectrum: Do not process learned records with a dummy FID · 577fa14d
      Ido Schimmel 提交于
      The switch periodically sends notifications about learned FDB entries.
      Among other things, the notification includes the FID (Filtering
      Identifier) and the port on which the MAC was learned.
      
      In case the driver does not have the FID defined on the relevant port,
      the following error will be periodically generated:
      
      mlxsw_spectrum2 0000:06:00.0 swp32: Failed to find a matching {Port, VID} following FDB notification
      
      This is not supposed to happen under normal conditions, but can happen
      if an ingress tc filter with a redirect action is installed on a bridged
      port. The redirect action will cause the packet's FID to be changed to
      the dummy FID and a learning notification will be emitted with this FID
      - which is not defined on the bridged port.
      
      Fix this by having the driver ignore learning notifications generated
      with the dummy FID and delete them from the device.
      
      Another option is to chain an ignore action after the redirect action
      which will cause the device to disable learning, but this means that we
      need to consume another action whenever a redirect action is used. In
      addition, the scenario described above is merely a corner case.
      
      Fixes: cedbb8b2 ("mlxsw: spectrum_flower: Set dummy FID before forward action")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reported-by: NAlex Kushnarov <alexanderk@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Tested-by: NAlex Kushnarov <alexanderk@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      577fa14d
    • P
      mlxsw: spectrum_dcb: Configure DSCP map as the last rule is removed · dedfde2f
      Petr Machata 提交于
      Spectrum systems use DSCP rewrite map to update DSCP field in egressing
      packets to correspond to priority that the packet has. Whether rewriting
      will take place is determined at the point when the packet ingresses the
      switch: if the port is in Trust L3 mode, packet priority is determined from
      the DSCP map at the port, and DSCP rewrite will happen. If the port is in
      Trust L2 mode, 802.1p is used for packet prioritization, and no DSCP
      rewrite will happen.
      
      The driver determines the port trust mode based on whether any DSCP
      prioritization rules are in effect at given port. If there are any, trust
      level is L3, otherwise it's L2. When the last DSCP rule is removed, the
      port is switched to trust L2. Under that scenario, if DSCP of a packet
      should be rewritten, it should be rewritten to 0.
      
      However, when switching to Trust L2, the driver neglects to also update the
      DSCP rewrite map. The last DSCP rule thus remains in effect, and packets
      egressing through this port, if they have the right priority, will have
      their DSCP set according to this rule.
      
      Fix by first configuring the rewrite map, and only then switching to trust
      L2 and bailing out.
      
      Fixes: b2b1dab6 ("mlxsw: spectrum: Support ieee_setapp, ieee_delapp")
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Reported-by: NAlex Veber <alexve@mellanox.com>
      Tested-by: NAlex Veber <alexve@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dedfde2f
  5. 16 7月, 2019 1 次提交
  6. 10 7月, 2019 5 次提交
  7. 06 7月, 2019 8 次提交
  8. 03 7月, 2019 1 次提交
  9. 02 7月, 2019 16 次提交