1. 14 11月, 2017 2 次提交
  2. 11 11月, 2017 1 次提交
  3. 24 7月, 2017 4 次提交
  4. 18 7月, 2017 1 次提交
  5. 02 5月, 2017 1 次提交
  6. 25 1月, 2017 1 次提交
  7. 14 12月, 2016 1 次提交
  8. 08 10月, 2016 1 次提交
    • J
      IB/mlx4: Fix possible vl/sl field mismatch in LRH header in QP1 packets · fd10ed8e
      Jack Morgenstein 提交于
      In MLX qp packets, the LRH (built by the driver) has both a VL field
      and an SL field. When building a QP1 packet, the VL field should
      reflect the SLtoVL mapping and not arbitrarily contain zero (as is
      done now). This bug causes credit problems in IB switches at
      high rates of QP1 packets.
      
      The fix is to cache the SL to VL mapping in the driver, and look up
      the VL mapped to the SL provided in the send request when sending
      QP1 packets.
      
      For FW versions which support generating a port_management_config_change
      event with subtype sl-to-vl-table-change, the driver uses that event
      to update its sl-to-vl mapping cache.  Otherwise, the driver snoops
      incoming SMP mads to update the cache.
      
      There remains the case where the FW is running in secure-host mode
      (so no QP0 packets are delivered to the driver), and the FW does not
      generate the sl2vl mapping change event. To support this case, the
      driver updates (via querying the FW) its sl2vl mapping cache when
      running in secure-host mode when it receives either a Port Up event
      or a client-reregister event (where the port is still up, but there
      may have been an opensm failover).
      OpenSM modifies the sl2vl mapping before Port Up and Client-reregister
      events occur, so if there is a mapping change the driver's cache will
      be properly updated.
      
      Fixes: 225c7b1f ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      fd10ed8e
  9. 17 9月, 2016 1 次提交
    • J
      IB/mlx4: Use correct subnet-prefix in QP1 mads under SR-IOV · 8ec07bf8
      Jack Morgenstein 提交于
      When sending QP1 MAD packets which use a GRH, the source GID
      (which consists of the 64-bit subnet prefix, and the 64 bit port GUID)
      must be included in the packet GRH.
      
      For SR-IOV, a GID cache is used, since the source GID needs to be the
      slave's source GID, and not the Hypervisor's GID. This cache also
      included a subnet_prefix. Unfortunately, the subnet_prefix field in
      the cache was never initialized (to the default subnet prefix 0xfe80::0).
      As a result, this field remained all zeroes.  Therefore, when SR-IOV
      was active, all QP1 packets which included a GRH had a source GID
      subnet prefix of all-zeroes.
      
      However, the subnet-prefix should initially be 0xfe80::0 (the default
      subnet prefix). In addition, if OpenSM modifies a port's subnet prefix,
      the new subnet prefix must be used in the GRH when sending QP1 packets.
      To fix this we now initialize the subnet prefix in the SR-IOV GID cache
      to the default subnet prefix. We update the cached value if/when OpenSM
      modifies the port's subnet prefix. We take this cached value when sending
      QP1 packets when SR-IOV is active.
      
      Note that the value is stored as an atomic64. This eliminates any need
      for locking when the subnet prefix is being updated.
      
      Note also that we depend on the FW generating the "port management change"
      event for tracking subnet-prefix changes performed by OpenSM. If running
      early FW (before 2.9.4630), subnet prefix changes will not be tracked (but
      the default subnet prefix still will be stored in the cache; therefore
      users who do not modify the subnet prefix will not have a problem).
      IF there is a need for such tracking also for early FW, we will add that
      capability in a subsequent patch.
      
      Fixes: 1ffeb2eb ("IB/mlx4: SR-IOV IB context objects and proxy/tunnel SQP support")
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      8ec07bf8
  10. 04 8月, 2016 1 次提交
    • M
      IB/mlx4: Add diagnostic hardware counters · 3f85f2aa
      Mark Bloch 提交于
      Expose IB diagnostic hardware counters.
      The counters count IB events and are applicable for IB and RoCE.
      
      The counters can be divided into two groups, per device and per port.
      Device counters are always exposed.
      Port counters are exposed only if the firmware supports per port counters.
      
      rq_num_dup and sq_num_to are only exposed if we have firmware support
      for them, if we do, we expose them per device and per port.
      rq_num_udsdprd and num_cqovf are device only counters.
      
      rq - denotes responder.
      sq - denotes requester.
      
      |-----------------------|---------------------------------------|
      |	Name		|	Description			|
      |-----------------------|---------------------------------------|
      |rq_num_lle		| Number of local length errors		|
      |-----------------------|---------------------------------------|
      |sq_num_lle		| number of local length errors		|
      |-----------------------|---------------------------------------|
      |rq_num_lqpoe		| Number of local QP operation errors	|
      |-----------------------|---------------------------------------|
      |sq_num_lqpoe		| Number of local QP operation errors	|
      |-----------------------|---------------------------------------|
      |rq_num_lpe		| Number of local protection errors	|
      |-----------------------|---------------------------------------|
      |sq_num_lpe		| Number of local protection errors	|
      |-----------------------|---------------------------------------|
      |rq_num_wrfe		| Number of CQEs with error		|
      |-----------------------|---------------------------------------|
      |sq_num_wrfe		| Number of CQEs with error		|
      |-----------------------|---------------------------------------|
      |sq_num_mwbe		| Number of Memory Window bind errors	|
      |-----------------------|---------------------------------------|
      |sq_num_bre		| Number of bad response errors		|
      |-----------------------|---------------------------------------|
      |sq_num_rire		| Number of Remote Invalid request	|
      |			| errors				|
      |-----------------------|---------------------------------------|
      |rq_num_rire		| Number of Remote Invalid request	|
      |			| errors				|
      |-----------------------|---------------------------------------|
      |sq_num_rae		| Number of remote access errors	|
      |-----------------------|---------------------------------------|
      |rq_num_rae		| Number of remote access errors	|
      |-----------------------|---------------------------------------|
      |sq_num_roe		| Number of remote operation errors	|
      |-----------------------|---------------------------------------|
      |sq_num_tree		| Number of transport retries exceeded	|
      |			| errors				|
      |-----------------------|---------------------------------------|
      |sq_num_rree		| Number of RNR NAK retries exceeded	|
      |			| errors				|
      |-----------------------|---------------------------------------|
      |rq_num_rnr		| Number of RNR NAKs sent		|
      |-----------------------|---------------------------------------|
      |sq_num_rnr		| Number of RNR NAKs received		|
      |-----------------------|---------------------------------------|
      |rq_num_oos		| Number of Out of Sequence requests	|
      |			| received				|
      |-----------------------|---------------------------------------|
      |sq_num_oos		| Number of Out of Sequence NAKs	|
      |			| received				|
      |-----------------------|---------------------------------------|
      |rq_num_udsdprd		| Number of UD packets silently		|
      |			| discarded on the Receive Queue due to	|
      |			| lack of receive descriptor		|
      |-----------------------|---------------------------------------|
      |rq_num_dup		| Number of duplicate requests received	|
      |-----------------------|---------------------------------------|
      |sq_num_to		| Number of time out received		|
      |-----------------------|---------------------------------------|
      |num_cqovf		| Number of CQ overflows		|
      |-----------------------|---------------------------------------|
      Signed-off-by: NMark Bloch <markb@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      3f85f2aa
  11. 23 6月, 2016 1 次提交
  12. 14 5月, 2016 2 次提交
  13. 02 3月, 2016 1 次提交
  14. 20 1月, 2016 2 次提交
  15. 24 12月, 2015 1 次提交
  16. 29 10月, 2015 2 次提交
  17. 22 10月, 2015 3 次提交
    • M
      IB/core: Use GID table in AH creation and dmac resolution · dbf727de
      Matan Barak 提交于
      Previously, vlan id and source MAC were used from QP attributes. Since
      the net device is now stored in the GID attributes, they could be used
      instead of getting this information from the QP attributes.
      
      IB_QP_SMAC, IB_QP_ALT_SMAC, IB_QP_VID and IB_QP_ALT_VID were removed
      because there is no known libibverbs that uses them.
      
      This commit also modifies the vendors (mlx4, ocrdma) drivers in order
      to use the new approach.
      
      ocrdma driver changes were done by Somnath Kotur <Somnath.Kotur@Avagotech.Com>
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      dbf727de
    • E
      IB/mlx4: Add counter based implementation for QP multicast loopback block · 7b59f0f9
      Eran Ben Elisha 提交于
      Current implementation for MLX4_IB_QP_BLOCK_MULTICAST_LOOPBACK is not
      supported when link layer is Ethernet.
      
      This patch will add counter based implementation for multicast loopback
      prevention. HW can drop multicast loopback packets if sender QP counter
      index is equal to receiver QP counter index. If qp flag
      MLX4_IB_QP_BLOCK_MULTICAST_LOOPBACK is set and link layer is Ethernet,
      create a new counter and attach it to the QP so it will continue
      receiving multicast loopback traffic but it's own.
      
      The decision if to create a new counter is being made at the qp
      modification to RTR after the QP's port is set. When QP is destroyed or
      moved back to reset state, delete the counter.
      Signed-off-by: NEran Ben Elisha <eranbe@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      7b59f0f9
    • E
      IB/mlx4: Add IB counters table · 3ba8e31d
      Eran Ben Elisha 提交于
      This is an infrastructure step for allocating and attaching more than
      one counter to QPs on the same port. Allocate a counters table and
      manage the insertion and removals of the counters in load and unload of
      mlx4 IB.
      Signed-off-by: NEran Ben Elisha <eranbe@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      3ba8e31d
  18. 31 8月, 2015 5 次提交
  19. 16 6月, 2015 1 次提交
  20. 13 6月, 2015 3 次提交
  21. 02 6月, 2015 1 次提交
  22. 31 5月, 2015 1 次提交
    • M
      net/mlx4: Add EQ pool · c66fa19c
      Matan Barak 提交于
      Previously, mlx4_en allocated EQs and used them exclusively.
      This affected RoCE performance, as applications which are
      events sensitive were limited to use only the legacy EQs.
      
      Change that by introducing an EQ pool. This pool is managed
      by mlx4_core. EQs are assigned to ports (when there are limited
      number of EQs, multiple ports could be assigned to the same EQs).
      
      An exception to this rule is the ASYNC EQ which handles various events.
      
      Legacy EQs are completely removed as all EQs could be shared.
      
      When a consumer (mlx4_ib/mlx4_en) requests an EQ, it asks for
      EQ serving on a specific port. The core driver calculates which
      EQ should be assigned to that request.
      
      Because IRQs are shared between IB and Ethernet modules, their
      names only include the PCI device BDF address.
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NIdo Shamay <idos@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c66fa19c
  23. 16 4月, 2015 3 次提交
    • Y
      IB/mlx4: Request alias GUID on demand · ee59fa0d
      Yishai Hadas 提交于
      Request GIDs from the SM on demand, i.e., when a VF actually needs them,
      and release them when the GIDs are no longer in use.
      
      In cloud environments, this is useful for GID migrations, in which a
      GID is assigned to a VF on the destination HCA, while the VF on the
      source HCA is shutdown (but the GID was not administratively released).
      Signed-off-by: NYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      ee59fa0d
    • Y
      IB/mlx4: Change init flow to request alias GUIDs for active VFs · f5479601
      Yishai Hadas 提交于
      Change the init flow to ask GUIDs only for active VFs. This is done for
      both SM & HOST modes so that there is no need any more to maintain the
      ownership record type.
      
      In case SM mode is used, the initial value will be 0, ask the SM to assign,
      for the HOST mode the initial value will be the HOST generated GUID.
      
      This will enable out of the box experience for both probed and attached VFs.
      Signed-off-by: NYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      f5479601
    • Y
      IB/mlx4: Alias GUID adding persistency support · 99ee4df6
      Yishai Hadas 提交于
      If the SM rejects an alias GUID request the PF driver keeps trying to acquire
      the specified GUID indefinitely, utilizing an exponential backoff scheme.
      
      Retrying is managed per GUID entry. Each entry that wasn't applied holds its
      next retry information. Retry requests to the SM consist of records of 8
      consecutive GUIDS. Each record that contains GUIDs requiring retries holds its
      next time-to-run based on the retry information of all its GUID entries. The
      record having the lowest retry time will run first when that retry time
      arrives.
      
      Since the method (SET or DELETE) as sent to the SM applies to all the GUIDs in
      the record, we must handle SET requests and DELETE requests in separate SM
      messages (one for SETs and the other for DELETEs).
      
      To avoid race conditions where a GUID entry request (set or delete) was
      modified after the SM request was sent, we save the method and the requested
      indices as part of the callback's context -- thus, only the requested indexes
      are evaluated when the response is received.
      
      When an GUID entry is approved we turn off its retry-required bit, this
      prevents redundant SM retries from occurring on that record.
      
      The port down event should be sent only when previously it was up. Likewise,
      the port up event should be sent only if previously the port was down.
      
      Synchronization was added around the flows that change entries and record state
      to prevent race conditions.
      Signed-off-by: NYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      99ee4df6