1. 13 11月, 2017 1 次提交
  2. 06 9月, 2017 1 次提交
  3. 04 9月, 2017 1 次提交
  4. 30 8月, 2017 2 次提交
  5. 25 8月, 2017 1 次提交
  6. 19 8月, 2017 1 次提交
  7. 17 8月, 2017 1 次提交
  8. 16 8月, 2017 1 次提交
  9. 03 8月, 2017 1 次提交
  10. 24 7月, 2017 1 次提交
  11. 03 7月, 2017 1 次提交
  12. 16 6月, 2017 1 次提交
    • S
      net/mlx4_en: Optimized single ring steering · 4931c6ef
      Saeed Mahameed 提交于
      Avoid touching RX QP RSS context when loading with only
      one RX ring, to allow optimized A0 RX steering.
      
      Enable by:
      - loading mlx4_core with module param: log_num_mgm_entry_size = -6.
      - then: ethtool -L <interface> rx 1
      
      Performance tests:
      Tested on ConnectX3Pro, Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz
      
      XDP_DROP packet rate:
      -------------------------------------
           | Before    | After     | Gain |
      IPv4 | 20.5 Mpps | 28.1 Mpps |  37% |
      IPv6 | 18.4 Mpps | 28.1 Mpps |  53% |
      -------------------------------------
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
      Cc: kernel-team@fb.com
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4931c6ef
  13. 08 6月, 2017 1 次提交
  14. 16 5月, 2017 1 次提交
  15. 17 3月, 2017 1 次提交
    • J
      net/mlx4_core: Avoid delays during VF driver device shutdown · 4cbe4dac
      Jack Morgenstein 提交于
      Some Hypervisors detach VFs from VMs by instantly causing an FLR event
      to be generated for a VF.
      
      In the mlx4 case, this will cause that VF's comm channel to be disabled
      before the VM has an opportunity to invoke the VF device's "shutdown"
      method.
      
      For such Hypervisors, there is a race condition between the VF's
      shutdown method and its internal-error detection/reset thread.
      
      The internal-error detection/reset thread (which runs every 5 seconds) also
      detects a disabled comm channel. If the internal-error detection/reset
      flow wins the race, we still get delays (while that flow tries repeatedly
      to detect comm-channel recovery).
      
      The cited commit fixed the command timeout problem when the
      internal-error detection/reset flow loses the race.
      
      This commit avoids the unneeded delays when the internal-error
      detection/reset flow wins.
      
      Fixes: d585df1c ("net/mlx4_core: Avoid command timeouts during VF driver device shutdown")
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Reported-by: NSimon Xiao <sixiao@microsoft.com>
      Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4cbe4dac
  16. 23 2月, 2017 3 次提交
  17. 31 1月, 2017 1 次提交
  18. 30 12月, 2016 1 次提交
    • J
      net/mlx4_core: Fix raw qp flow steering rules under SRIOV · 10b1c04e
      Jack Morgenstein 提交于
      Demoting simple flow steering rule priority (for DPDK) was achieved by
      wrapping FW commands MLX4_QP_FLOW_STEERING_ATTACH/DETACH for the PF
      as well, and forcing the priority to MLX4_DOMAIN_NIC in the wrapper
      function for the PF and all VFs.
      
      In function mlx4_ib_create_flow(), this change caused the main rule
      creation for the PF to be wrapped, while it left the associated
      tunnel steering rule creation unwrapped for the PF.
      
      This mismatch caused rule deletion failures in mlx4_ib_destroy_flow()
      for the PF when the detach wrapper function did not find the associated
      tunnel-steering rule (since creation of that rule for the PF did not
      go through the wrapper function).
      
      Fix this by setting MLX4_QP_FLOW_STEERING_ATTACH/DETACH to be "native"
      (so that the PF invocation does not go through the wrapper), and perform
      the required priority demotion for the PF in the mlx4_ib_create_flow()
      code path.
      
      Fixes: 48564135 ("net/mlx4_core: Demote simple multicast and broadcast flow steering rules")
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      10b1c04e
  19. 25 12月, 2016 1 次提交
  20. 29 11月, 2016 1 次提交
    • T
      Revert "net/mlx4_en: Avoid unregister_netdev at shutdown flow" · b4353708
      Tariq Toukan 提交于
      This reverts commit 9d769311.
      
      Using unregister_netdev at shutdown flow prevents calling
      the netdev's ndos or trying to access its freed resources.
      
      This fixes crashes like the following:
       Call Trace:
        [<ffffffff81587a6e>] dev_get_phys_port_id+0x1e/0x30
        [<ffffffff815a36ce>] rtnl_fill_ifinfo+0x4be/0xff0
        [<ffffffff815a53f3>] rtmsg_ifinfo_build_skb+0x73/0xe0
        [<ffffffff815a5476>] rtmsg_ifinfo.part.27+0x16/0x50
        [<ffffffff815a54c8>] rtmsg_ifinfo+0x18/0x20
        [<ffffffff8158a6c6>] netdev_state_change+0x46/0x50
        [<ffffffff815a5e78>] linkwatch_do_dev+0x38/0x50
        [<ffffffff815a6165>] __linkwatch_run_queue+0xf5/0x170
        [<ffffffff815a6205>] linkwatch_event+0x25/0x30
        [<ffffffff81099a82>] process_one_work+0x152/0x400
        [<ffffffff8109a325>] worker_thread+0x125/0x4b0
        [<ffffffff8109a200>] ? rescuer_thread+0x350/0x350
        [<ffffffff8109fc6a>] kthread+0xca/0xe0
        [<ffffffff8109fba0>] ? kthread_park+0x60/0x60
        [<ffffffff816a1285>] ret_from_fork+0x25/0x30
      
      Fixes: 9d769311 ("net/mlx4_en: Avoid unregister_netdev at shutdown flow")
      Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
      Reported-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
      Reported-by: NSteve Wise <swise@opengridcomputing.com>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4353708
  21. 18 11月, 2016 1 次提交
  22. 30 10月, 2016 1 次提交
  23. 22 9月, 2016 1 次提交
  24. 05 7月, 2016 1 次提交
  25. 24 6月, 2016 1 次提交
  26. 23 6月, 2016 1 次提交
  27. 16 6月, 2016 1 次提交
    • E
      net/mlx4_en: initialize cmd.context_lock spinlock earlier · 0c5ddb51
      Eric Dumazet 提交于
      Maciej Żenczykowski reported lockdep warning a spinlock
      was not registered before being held in mlx4_cmd_wake_completions()
      
      cmd.context_lock initialization is not at the right place.
      
      1) mlx4_cmd_use_events() can be called multiple times.
         Calling spin_lock_init() on a live spinlock can lead
         to hangs.
      
      2) mlx4_cmd_wake_completions() can be called while lock
         has not been initialized.
         Lockdep complains, and current logic is not race prone.
      
      It seems better to move the initialization earlier in
      mlx4_load_one()
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NMaciej Żenczykowski <maze@google.com>
      Cc: Eugenia Emantayev <eugenia@mellanox.com>
      Cc: Tariq Toukan <tariqt@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c5ddb51
  28. 22 4月, 2016 2 次提交
  29. 19 3月, 2016 1 次提交
  30. 03 3月, 2016 1 次提交
  31. 02 3月, 2016 2 次提交
  32. 17 2月, 2016 1 次提交
    • H
      net/mlx4_core: Set UAR page size to 4KB regardless of system page size · 85743f1e
      Huy Nguyen 提交于
      problem description:
      
      The current code sets UAR page size equal to system page size.
      The ConnectX-3 and ConnectX-3 Pro HWs require minimum 128 UAR pages.
      The mlx4 kernel drivers are not loaded if there is less than 128 UAR pages.
      
      solution:
      
      Always set UAR page to 4KB. This allows more UAR pages if the OS
      has PAGE_SIZE larger than 4KB. For example, PowerPC kernel use 64KB
      system page size, with 4MB uar region, there are 4MB/2/64KB = 32
      uars (half for uar, half for blueflame). This does not meet minimum 128
      UAR pages requirement. With 4KB UAR page, there are 4MB/2/4KB = 512 uars
      which meet the minimum requirement.
      
      Note that only codes in mlx4_core that deal with firmware know that uar
      page size is 4KB. Codes that deal with usr page in cq and qp context
      (mlx4_ib, mlx4_en and part of mlx4_core) still have the same assumption
      that uar page size equals to system page size.
      
      Note that with this implementation, on 64KB system page size kernel, there
      are 16 uars per system page but only one uars is used. The other 15
      uars are ignored because of the above assumption.
      
      Regarding SR-IOV, mlx4_core in hypervisor will set the uar page size
      to 4KB and mlx4_core code in virtual OS will obtain the uar page size from
      firmware.
      
      Regarding backward compatibility in SR-IOV, if hypervisor has this new code,
      the virtual OS must be updated. If hypervisor has old code, and the virtual
      OS has this new code, the new code will be backward compatible with the
      old code. If the uar size is big enough, this new code in VF continues to
      work with 64 KB uar page size (on PowerPc kernel). If the uar size does not
      meet 128 uars requirement, this new code not loaded in VF and print the same
      error message as the old code in Hypervisor.
      Signed-off-by: NHuy Nguyen <huyn@mellanox.com>
      Reviewed-by: NYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      85743f1e
  33. 07 12月, 2015 1 次提交
  34. 16 11月, 2015 1 次提交
  35. 15 10月, 2015 1 次提交
    • J
      net/mlx4_core: Replace VF zero mac with random mac in mlx4_core · 2b3ddf27
      Jack Morgenstein 提交于
      By design, when no default MAC addresses are set in the Hypervisor for VFs,
      the VFs are passed zero-macs. When such a MAC is received by the VF, it
      generates a random MAC address and registers that MAC address
      with the Hypervisor.
      
      This random mac generation is currently done in the mlx4_en module.
      There is a problem, though, if the mlx4_ib module is loaded by a VF before
      the mlx4_en module. In this case, for RoCE, mlx4_ib will see the un-replaced
      zero-mac and register that zero-mac as part of QP1 initialization.
      
      Having a zero-mac in the port's MAC table creates problems for a
      Baseboard Management Console. The BMC occasionally sends packets with a
      zero-mac destination MAC. If there is a zero-mac present in the port's
      MAC table, the FW will send such BMC packets to the host driver rather than
      to the wire, and BMC will stop working.
      
      To address this problem, we move the replacement of zero-mac addresses
      with random-mac addresses to procedure mlx4_slave_cap(), which is part of the
      driver startup for VFs, and is before activation of mlx4_ib and mlx4_en.
      As a result, zero-mac addresses will never be registered in the port MAC table
      by the driver.
      
      In addition, when mlx4_en does initialize the net device, it needs to set
      the NET_ADDR_RANDOM flag in the netdev structure if the address was
      randomly generated. This is done so that udev on the VM does not create
      a new device name after each VF probe (VM boot and such). To accomplish this,
      we add a per-port flag in mlx4_dev which gets set whenever mlx4_core replaces
      a zero-mac with a randomly-generated mac. This flag is examined when mlx4_en
      initializes the net-device.
      
      Fix was suggested by Matan Barak <matanb@mellanox.com>
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2b3ddf27