1. 02 Nov, 2017 1 commit
  2. 21 Oct, 2017 3 commits
  3. 12 Oct, 2017 1 commit
  4. 24 Aug, 2017 1 commit
  5. 20 Aug, 2017 1 commit
  6. 18 Aug, 2017 1 commit
  7. 11 Aug, 2017 1 commit
  8. 07 Aug, 2017 6 commits
  9. 19 Jun, 2017 2 commits
  10. 15 Jun, 2017 2 commits
  11. 08 Jun, 2017 1 commit
  12. 30 Apr, 2017 5 commits
    • Hadar Hen Zion's avatar
      net/mlx5e: Act on delay probe time updates · a2fa1fe5
      Hadar Hen Zion authored
      
      
      The user can change delay_first_probe_time parameter through sysctl.
      Listen to NETEVENT_DELAY_PROBE_TIME_UPDATE notifications and update the
      intervals for updating the neighbours 'used' value periodic task and
      for flow HW counters query periodic task.
      Both of the intervals will be update only in case the new delay prob
      time value is lower the current interval.
      
      Since the driver saves only one min interval value and not per device,
      the users will be able to set lower interval value for updating
      neighbour 'used' value periodic task but they won't be able to schedule
      a higher interval for this periodic task.
      The used interval for scheduling neighbour 'used' value periodic task is
      the minimal delay prob time parameter ever seen by the driver.
      Signed-off-by: default avatarHadar Hen Zion <hadarh@mellanox.com>
      Reviewed-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      a2fa1fe5
    • Hadar Hen Zion's avatar
      net/mlx5e: Update neighbour 'used' state using HW flow rules counters · f6dfb4c3
      Hadar Hen Zion authored
      
      
      When IP tunnel encapsulation rules are offloaded, the kernel can't see
      the traffic of the offloaded flow. The neighbour for the IP tunnel
      destination of the offloaded flow can mistakenly become STALE and
      deleted by the kernel since its 'used' value wasn't changed.
      
      To make sure that a neighbour which is used by the HW won't become
      STALE, we proactively update the neighbour 'used' value every
      DELAY_PROBE_TIME period, when packets were matched and counted by the HW
      for one of the tunnel encap flows related to this neighbour.
      
      The periodic task that updates the used neighbours is scheduled when a
      tunnel encap rule is successfully offloaded into HW and keeps re-scheduling
      itself as long as the representor's neighbours list isn't empty.
      
      Add, remove, lookup and status change operations done over the
      representor's neighbours list or the neighbour hash entry encaps list
      are all serialized by RTNL lock.
      Signed-off-by: default avatarHadar Hen Zion <hadarh@mellanox.com>
      Reviewed-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      f6dfb4c3
    • Hadar Hen Zion's avatar
      net/mlx5e: Add support to neighbour update flow · 232c0013
      Hadar Hen Zion authored
      
      
      In order to offload TC encap rules, the driver does a lookup for the IP
      tunnel neighbour according to the output device and the destination IP
      given by the user.
      
      To keep tracking after the validity state of such neighbours, we keep
      the neighbours information (pair of device pointer and destination IP)
      in a hash table maintained at the relevant egress representor and
      register to get NETEVENT_NEIGH_UPDATE events. When getting neighbour update
      netevent, we search for a match among the cached neighbours entries used for
      encapsulation.
      
      In case the neighbour isn't valid, we can't offload the flow into the
      HW. We cache the flow (requested matching and actions) in the driver and
      offload the rule later, when the neighbour is resolved and becomes
      valid.
      
      When a flow is only cached in the driver and not offloaded into HW
      yet, we use EAGAIN return value to mark it internally, the TC ndo still
      returns success.
      
      Listen to kernel neighbour update netevents to trace relevant neighbours
      validity state:
      
      1. If a neighbour becomes valid, offload the related rules to HW.
      
      2. If the neighbour becomes invalid, remove the related rules from HW.
      
      3. If the neighbour mac address was changed, update the encap header.
         Remove all the offloaded rules using the old encap header from the HW
         and insert new rules to HW with updated encap header.
      
      Access to the neighbors hash table is protected by RTNL lock of its
      caller or by the table's spinlock.
      
      Details of the locking/synchronization among the different actions
      applied on the neighbour table:
      
      Add/remove operations - protected by RTNL lock of its caller (all TC
      commands are protected by RTNL lock). Add and remove operations are
      initiated only when the user inserts/removes a TC rule into/from the driver.
      
      Lookup/remove operations - since the lookup operation is done from
      netevent notifier block, RTNL lock can't be used (atomic context).
      Use the table's spin lock to protect lookups from TC user removal operation.
      bh is used since netevent can be called from a softirq context.
      
      Lookup/add operations - The hash table access functions are taking
      care of the protection between lookup and add operations.
      
      When adding/removing encap headers and rules to/from the HW, RTNL lock
      is used. It can happen when:
      
      1. The user inserts/removes a TC rule into/from the driver (TC commands
      are protected by RTNL lock of it's caller).
      
      2. The driver gets neighbour notification event, which reports about
      neighbour validity status change. Before adding/removing encap headers
      and rules to/from the HW, RTNL lock is taken.
      
      A neighbour hash table entry should be freed when its encap list is empty.
      Since The neighbour update netevent notification schedules a neighbour
      update work that uses the neighbour hash entry, it can't be freed
      unconditionally when the encap list becomes empty during TC delete rule flow.
      Use reference count to protect from freeing neighbour hash table entry
      while it's still in use.
      
      When the user asks to unregister a netdvice used by one of the neigbours,
      neighbour removal notification is received. Then we take a reference on the
      neighbour and don't free it until the relevant encap entries (and flows) are
      marked as invalid (not offloaded) and removed from HW.
      As long as the encap entry is still valid (checked under RTNL lock) we
      can safely access the neighbour device saved on mlx5e_neigh struct.
      Signed-off-by: default avatarHadar Hen Zion <hadarh@mellanox.com>
      Reviewed-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      232c0013
    • Hadar Hen Zion's avatar
      net/mlx5e: Add neighbour hash table to the representors · 37b498ff
      Hadar Hen Zion authored
      
      
      Add hash table to the representors which is to be used by the next patch
      to save neighbours information in the driver.
      
      In order to offload IP tunnel encapsulation rules, the driver must find
      the tunnel dst neighbour according to the output device and the
      destination address given by the user. The next patch will cache the
      neighbors information in the driver to allow support in neigh update
      flow for tunnel encap rules.
      
      The neighbour entries are also saved in a list so we easily iterate over
      them when querying statistics in order to provide 'used' feedback to the
      kernel neighbour NUD core.
      Signed-off-by: default avatarHadar Hen Zion <hadarh@mellanox.com>
      Reviewed-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      37b498ff
    • Saeed Mahameed's avatar
      net/mlx5e: Extendable vport representor netdev private data · 1d447a39
      Saeed Mahameed authored
      
      
      Make representor netdev private data extendable by adding new struct
      "mlx5e_rep_priv" and use it as the rep netdev private data struct
      instead of directly pointing to mlx5_eswitch_rep.
      
      Added new en_rep.h header file to contain all representor related
      definitions and prototypes, and moved all representor specific logic
      into en_rep.c.
      
      Needed for downstream patches to extend representor functionality to
      support neighbour update.
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Reviewed-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      1d447a39
  13. 17 Apr, 2017 3 commits
  14. 27 Mar, 2017 3 commits
  15. 22 Mar, 2017 1 commit
    • Paul Blakey's avatar
      net/mlx5e: Avoid supporting udp tunnel port ndo for VF reps · 1ad9a00a
      Paul Blakey authored
      This was added to allow the TC offloading code to identify offloading
      encap/decap vxlan rules.
      
      The VF reps are effectively related to the same mlx5 PCI device as the
      PF. Since the kernel invokes the (say) delete ndo for each netdev, the
      FW erred on multiple vxlan dst port deletes when the port was deleted
      from the system.
      
      We fix that by keeping the registration to be carried out only by the
      PF. Since the PF serves as the uplink device, the VF reps will look
      up a port there and realize if they are ok to offload that.
      
      Tested:
       <SETUP VFS>
       <SETUP switchdev mode to have representors>
       ip link add vxlan1 type vxlan id 44 dev ens5f0 dstport 9999
       ip link set vxlan1 up
       ip link del dev vxlan1
      
      Fixes: 4a25730e
      
       ('net/mlx5e: Add ndo_udp_tunnel_add to VF representors')
      Signed-off-by: default avatarPaul Blakey <paulb@mellanox.com>
      Reviewed-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ad9a00a
  16. 08 Jan, 2017 1 commit
  17. 02 Dec, 2016 3 commits
  18. 24 Nov, 2016 2 commits
  19. 09 Nov, 2016 1 commit
  20. 04 Nov, 2016 1 commit