1. 06 1月, 2009 1 次提交
  2. 31 12月, 2008 1 次提交
  3. 30 12月, 2008 6 次提交
  4. 27 12月, 2008 1 次提交
  5. 25 12月, 2008 4 次提交
  6. 23 12月, 2008 1 次提交
  7. 22 12月, 2008 3 次提交
    • Y
      mlx4_core: Add support for multiple completion event vectors · b8dd786f
      Yevgeny Petrilin 提交于
      When using MSI-X mode, create a completion event queue for each CPU.
      Report the number of completion EQs in a new struct mlx4_caps member,
      num_comp_vectors, and extend the mlx4_cq_alloc() interface with a
      vector parameter so that consumers can specify which completion EQ
      should be used to report events for the CQ being created.
      Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      b8dd786f
    • D
      IB/iser: Avoid recv buffer exhaustion caused by unexpected PDUs · bba7ebba
      David Disseldorp 提交于
      iSCSI/iSER targets may send PDUs without a prior request from the
      initiator.  RFC 5046 refers to these PDUs as "unexpected".  NOP-In PDUs
      with itt=RESERVED and Asynchronous Message PDUs occupy this category.
      
      The amount of active "unexpected" PDU's an iSER target may have at any
      time is governed by the MaxOutstandingUnexpectedPDUs key, which is not
      yet supported.
      
      Currently when an iSER target sends an "unexpected" PDU, the
      initiators recv buffer consumed by the PDU is not replaced.  If over
      initial_post_recv_bufs_num "unexpected" PDUs are received then the
      receive queue will run out of receive work requests entirely.
      
      This patch ensures recv buffers consumed by "unexpected" PDUs are
      replaced in the next iser_post_receive_control() call.
      Signed-off-by: NDavid Disseldorp <ddiss@sgi.com>
      Signed-off-by: NKen Sandars <ksandars@sgi.com>
      Acked-by: NOr Gerlitz <ogerlitz@voltaire.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      bba7ebba
    • J
      IB/ehca: Remove redundant test of vpage · 139cdab0
      Julia Lawall 提交于
      vpage is checked not to be NULL just after it is initialized at the
      beginning of each loop iteration.
      
      A simplified version of the semantic patch that makes this change is
      as follows: (http://www.emn.fr/x-info/coccinelle/)
      
      // <smpl>
      @r exists@
      local idexpression x;
      expression E;
      position p1,p2;
      @@
      
      if (x@p1 == NULL || ...) { ... when forall
         return ...; }
      ... when != \(x=E\|x--\|x++\|--x\|++x\|x-=E\|x+=E\|x|=E\|x&=E\|&x\)
      (
      x@p2 == NULL
      |
      x@p2 != NULL
      )
      
      // another path to the test that is not through p1?
      @s exists@
      local idexpression r.x;
      position r.p1,r.p2;
      @@
      
      ... when != x@p1
      (
      x@p2 == NULL
      |
      x@p2 != NULL
      )
      
      @fix depends on !s@
      position r.p1,r.p2;
      expression x,E;
      statement S1,S2;
      @@
      
      (
      - if ((x@p2 != NULL) || ...)
        S1
      |
      - if ((x@p2 == NULL) && ...) S1
      |
      - BUG_ON(x@p2 == NULL);
      )
      // </smpl>
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      139cdab0
  8. 06 12月, 2008 15 次提交
  9. 02 12月, 2008 6 次提交
  10. 25 11月, 2008 1 次提交
  11. 13 11月, 2008 1 次提交
    • Y
      IPoIB: Fix crash in path_rec_completion() · ff79ae80
      Yossi Etigin 提交于
      Fix a crash in path_rec_completion() during an SM up/down loop.  If
      more than one path record request is issued, the first completion
      releases path->done, allowing ipoib_flush_paths() to free the path,
      and thus corrupting it for the second completion.
      
      Commit ee1e2c82 ("IPoIB: Refresh paths instead of flushing them on SM
      change events") added the field path->valid and changed the test "if
      (!path)" to "if (!path || !path->valid)".  This change made it
      possible for a path with an outstanding query to pass the test and
      issue another query on the same path.  Having two queries on the same
      path leads to a crash.
      
      This fixes <https://bugs.openfabrics.org/show_bug.cgi?id=1325>.
      Signed-off-by: NYossi Etigin <yosefe@voltaire.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      ff79ae80