1. 31 3月, 2020 2 次提交
    • I
      mlxsw: spectrum: Track used packet trap policer IDs · 03484e49
      Ido Schimmel 提交于
      During initialization the driver configures various packet trap groups
      and binds policers to them.
      
      Currently, most of these groups are not exposed to user space and
      therefore their policers should not be exposed as well. Otherwise, user
      space will be able to alter policer parameters without knowing which
      packet traps are policed by the policer.
      
      Use a bitmap to track the used policer IDs so that these policers will
      not be registered with devlink in a subsequent patch.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      03484e49
    • J
      net: sched: expose HW stats types per action used by drivers · 93a129eb
      Jiri Pirko 提交于
      It may be up to the driver (in case ANY HW stats is passed) to select
      which type of HW stats he is going to use. Add an infrastructure to
      expose this information to user.
      
      $ tc filter add dev enp3s0np1 ingress proto ip handle 1 pref 1 flower dst_ip 192.168.1.1 action drop
      $ tc -s filter show dev enp3s0np1 ingress
      filter protocol ip pref 1 flower chain 0
      filter protocol ip pref 1 flower chain 0 handle 0x1
        eth_type ipv4
        dst_ip 192.168.1.1
        in_hw in_hw_count 2
              action order 1: gact action drop
               random type none pass val 0
               index 1 ref 1 bind 1 installed 10 sec used 10 sec
              Action statistics:
              Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
              backlog 0b 0p requeues 0
              used_hw_stats immediate     <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93a129eb
  2. 27 3月, 2020 1 次提交
  3. 20 3月, 2020 1 次提交
  4. 19 3月, 2020 1 次提交
  5. 09 3月, 2020 1 次提交
  6. 06 3月, 2020 2 次提交
  7. 27 2月, 2020 1 次提交
  8. 26 2月, 2020 2 次提交
  9. 25 2月, 2020 3 次提交
  10. 24 2月, 2020 1 次提交
  11. 23 2月, 2020 2 次提交
    • I
      mlxsw: spectrum_router: Take router lock from netdev listener · b43c12e7
      Ido Schimmel 提交于
      One entry point into the routing code is from the netdev listener block.
      Some netdev events require access to internal router structures. For
      example, changing the MTU of a netdev requires looking-up the backing
      RIF and adjusting its MTU.
      
      In order to serialize access to shared router structures, take the
      router lock when processing netdev events that require access to it.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b43c12e7
    • I
      mlxsw: spectrum_router: Store NVE decapsulation configuration in router · 8e18d85e
      Ido Schimmel 提交于
      When a host route is added, the driver checks if the route needs to be
      promoted to perform NVE decapsulation based on the current NVE
      configuration. If so, the index of the decapsulation entry is retrieved
      and associated with the route.
      
      Currently, this information is stored in the NVE module which the router
      module consults. Since the information is protected under RTNL and since
      route insertion happens with RTNL held, there is no problem to retrieve
      the information from the NVE module.
      
      However, this is going to change and route insertion will no longer
      happen under RTNL. Instead, a dedicated lock will be introduced for the
      router module.
      
      Therefore, store this information in the router module and change the
      router module to consult this copy.
      
      The validity of the information is set / cleared whenever an NVE tunnel
      is initialized / de-initialized. When this happens the NVE module calls
      into the router module to promote / demote the relevant host route.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e18d85e
  12. 21 2月, 2020 3 次提交
  13. 18 2月, 2020 1 次提交
  14. 25 1月, 2020 3 次提交
  15. 20 1月, 2020 3 次提交
  16. 19 12月, 2019 1 次提交
  17. 01 11月, 2019 3 次提交
  18. 19 10月, 2019 1 次提交
  19. 05 10月, 2019 2 次提交
  20. 29 8月, 2019 2 次提交
  21. 22 8月, 2019 1 次提交
  22. 30 7月, 2019 1 次提交
    • P
      mlxsw: spectrum_ptp: Increase parsing depth when PTP is enabled · c6b36bdd
      Petr Machata 提交于
      Spectrum systems have a configurable limit on how far into the packet they
      parse. By default, the limit is 96 bytes.
      
      An IPv6 PTP packet is layered as Ethernet/IPv6/UDP (14+40+8 bytes), and
      sequence ID of a PTP event is only available 32 bytes into payload, for a
      total of 94 bytes. When an additional 802.1q header is present as
      well (such as when ptp4l is running on a VLAN port), the parsing limit is
      exceeded. Such packets are not recognized as PTP, and are not timestamped.
      
      Therefore generalize the current VXLAN-specific parsing depth setting to
      allow reference-counted requests from other modules as well. Keep it in the
      VXLAN module, because the MPRS register also configures UDP destination
      port number used for VXLAN, and is thus closely tied to the VXLAN code
      anyway.
      
      Then invoke the new interfaces from both VXLAN (in obvious places), as well
      as from PTP code, when the (global) timestamping configuration changes from
      disabled to enabled or vice versa.
      
      Fixes: 87486427 ("mlxsw: spectrum: PTP: Support SIOCGHWTSTAMP, SIOCSHWTSTAMP ioctls")
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c6b36bdd
  23. 28 7月, 2019 1 次提交
  24. 18 7月, 2019 1 次提交
    • 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