1. 22 10月, 2015 2 次提交
  2. 29 9月, 2015 1 次提交
  3. 31 8月, 2015 4 次提交
  4. 29 8月, 2015 1 次提交
  5. 15 7月, 2015 4 次提交
  6. 16 6月, 2015 1 次提交
  7. 13 6月, 2015 5 次提交
  8. 02 6月, 2015 1 次提交
  9. 31 5月, 2015 2 次提交
  10. 21 5月, 2015 2 次提交
  11. 19 5月, 2015 1 次提交
  12. 13 5月, 2015 1 次提交
  13. 16 4月, 2015 2 次提交
  14. 03 4月, 2015 1 次提交
  15. 19 3月, 2015 1 次提交
  16. 17 2月, 2015 1 次提交
  17. 10 2月, 2015 2 次提交
    • Y
      IB/mlx4: Reset flow support for IB kernel ULPs · 35f05dab
      Yishai Hadas 提交于
      The driver exposes interfaces that directly relate to HW state. Upon fatal
      error, consumers of these interfaces (ULPs) that rely on completion of
      all their posted work-request could hang, thereby introducing dependencies
      in shutdown order.  To prevent this from happening, we manage the
      relevant resources (CQs, QPs) that are used by the device. Upon a fatal error,
      we now generate simulated completions for outstanding WQEs that were not
      completed at the time the HW was reset.
      
      It includes invoking the completion event handler for all involved CQs so that
      the ULPs will poll those CQs. When polled we return simulated CQEs with
      IB_WC_WR_FLUSH_ERR return code enabling ULPs to clean up their resources and
      not wait forever for completions upon receiving remove_one.
      
      The above change requires an extra check in the data path to make sure that when
      device is in error state, the simulated CQEs will be returned and no further
      WQEs will be posted.
      Signed-off-by: NYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      35f05dab
    • M
      IB/mlx4: Always use the correct port for mirrored multicast attachments · 824c25c1
      Moni Shoua 提交于
      When attaching a QP to a multicast address in bonded mode, there was an
      assumption that the port of the QP must be #1. This assumption isn't the
      case under the flow which enables maximal usage of the physical ports.
      
      Fix it by always checking the port of the original flow and create the
      mirrored flow on the other port.
      
      Fixes: c6215745 ('IB/mlx4: Load balance ports in port aggregation mode')
      Signed-off-by: NMoni Shoua <monis@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      824c25c1
  18. 05 2月, 2015 3 次提交
  19. 26 1月, 2015 1 次提交
  20. 16 1月, 2015 1 次提交
  21. 12 12月, 2014 1 次提交
    • E
      net/mlx4: Change QP allocation scheme · ddae0349
      Eugenia Emantayev 提交于
      When using BF (Blue-Flame), the QPN overrides the VLAN, CV, and SV fields
      in the WQE. Thus, BF may only be used for QPNs with bits 6,7 unset.
      
      The current Ethernet driver code reserves a Tx QP range with 256b alignment.
      
      This is wrong because if there are more than 64 Tx QPs in use,
      QPNs >= base + 65 will have bits 6/7 set.
      
      This problem is not specific for the Ethernet driver, any entity that
      tries to reserve more than 64 BF-enabled QPs should fail. Also, using
      ranges is not necessary here and is wasteful.
      
      The new mechanism introduced here will support reservation for
      "Eth QPs eligible for BF" for all drivers: bare-metal, multi-PF, and VFs
      (when hypervisors support WC in VMs). The flow we use is:
      
      1. In mlx4_en, allocate Tx QPs one by one instead of a range allocation,
         and request "BF enabled QPs" if BF is supported for the function
      
      2. In the ALLOC_RES FW command, change param1 to:
      a. param1[23:0]  - number of QPs
      b. param1[31-24] - flags controlling QPs reservation
      
      Bit 31 refers to Eth blueflame supported QPs. Those QPs must have
      bits 6 and 7 unset in order to be used in Ethernet.
      
      Bits 24-30 of the flags are currently reserved.
      
      When a function tries to allocate a QP, it states the required attributes
      for this QP. Those attributes are considered "best-effort". If an attribute,
      such as Ethernet BF enabled QP, is a must-have attribute, the function has
      to check that attribute is supported before trying to do the allocation.
      
      In a lower layer of the code, mlx4_qp_reserve_range masks out the bits
      which are unsupported. If SRIOV is used, the PF validates those attributes
      and masks out unsupported attributes as well. In order to notify VFs which
      attributes are supported, the VF uses QUERY_FUNC_CAP command. This command's
      mailbox is filled by the PF, which notifies which QP allocation attributes
      it supports.
      Signed-off-by: NEugenia Emantayev <eugenia@mellanox.co.il>
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ddae0349
  22. 14 11月, 2014 1 次提交
  23. 31 10月, 2014 1 次提交
    • O
      mlx4: Avoid leaking steering rules on flow creation error flow · 571e1b2c
      Or Gerlitz 提交于
      If mlx4_ib_create_flow() attempts to create > 1 rules with the
      firmware, and one of these registrations fail, we leaked the
      already created flow rules.
      
      One example of the leak is when the registration of the VXLAN ghost
      steering rule fails, we didn't unregister the original rule requested
      by the user, introduced in commit d2fce8a9 "mlx4: Set
      user-space raw Ethernet QPs to properly handle VXLAN traffic".
      
      While here, add dump of the VXLAN portion of steering rules
      so it can actually be seen when flow creation fails.
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      571e1b2c