Sean Hefty [Tue, 5 Oct 2010 18:30:06 +0000 (11:30 -0700)]
librdmacm: only allocate qp in rdma_create_ep if qp_attr provided
The comments and documentation for rdma_create_ep indicate that
it will only allocate a QP if initial QP attributes are provided.
However, the code always attempts to create a QP off an
active rdma_cm_id endpoint.
By _not_ allocating the QP, a user can first determine
what RDMA device an rdma_cm_id was associated with (returned from
rdma_create_ep). The user can then call rdma_create_qp to
allocate a QP referencing an existing CQ, SRQ, or PD.
Sean Hefty [Tue, 5 Oct 2010 18:30:06 +0000 (11:30 -0700)]
librdmacm: only allocate qp in rdma_create_ep if qp_attr provided
The comments and documentation for rdma_create_ep indicate that
it will only allocate a QP if initial QP attributes are provided.
However, the code always attempts to create a QP off an
active rdma_cm_id endpoint.
By _not_ allocating the QP, a user can first determine
what RDMA device an rdma_cm_id was associated with (returned from
rdma_create_ep). The user can then call rdma_create_qp to
allocate a QP referencing an existing CQ, SRQ, or PD.
Sean Hefty [Fri, 17 Sep 2010 21:17:20 +0000 (14:17 -0700)]
dapl/ibal: delay QP transition until user disconnects
The ibal provider calls ib_cm_drep in response to receiving
a dreq. The result is that the user's QP is transitioned
through the error state, which fails any outstanding send
operations and flushes all receives. The disconnect request
is then reported to the user.
Since a user can receive errors from the QP before they are
aware of a pending disconnect request, the application may
respond to the errors as, well, actual errors. Fix this by
delaying the QP transition until the user responds to the
dreq.
This fixes an error with Intel MPI running over the ibal
dapl provider with a 'spawn' test.
Stan Smith [Fri, 1 Oct 2010 16:56:14 +0000 (16:56 +0000)]
[IPoIB_NDIS6_CM] oops - checked in the wrong set of files for EndPoint initialization; this commits fixes commit 2951 (ipoib_endpt_create() needs p_port passed in).
Leonid Kelly [Mon, 27 Sep 2010 19:32:11 +0000 (19:32 +0000)]
[HCA] Prevent stack corruption
In the case where umv_buf::command is FALSE, the else control segment is taken and a stack variable's address is stored by INIT_UDATA, to be written later in the call to alloc_pd. The stack variable then goes out of scope, so the call to alloc_pd could corrupt the stack.
The fix uses the status local variable as temporary storage, as it is unused until after the call to alloc_pd.
Signed-off-by: Fab Tillier <ftillier@microsoft.com>
git-svn-id: svn://openib.tc.cornell.edu/gen1@2948 ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86
Sean Hefty [Thu, 23 Sep 2010 19:25:29 +0000 (12:25 -0700)]
ibal: send drep in response to unmatched dreq
If a DREQ is received that cannot be matched with an
existing CEP, issue a DREP in response. It's possible
that the targetted CEP issued a DREP which was lost.
The CEP then transitioned through the timewait state
before another DREQ was received, and is no longer accessible.
To prevent the remote side from timing out waiting on a DREP,
send one so that it can complete its disconnection.
This fixes an issue in iMPI where one side of a connection
ends up waiting up to two minutes on disconnection.
Sean Hefty [Thu, 23 Sep 2010 19:25:29 +0000 (12:25 -0700)]
ibal: send drep in response to unmatched dreq
If a DREQ is received that cannot be matched with an
existing CEP, issue a DREP in response. It's possible
that the targetted CEP issued a DREP which was lost.
The CEP then transitioned through the timewait state
before another DREQ was received, and is no longer accessible.
To prevent the remote side from timing out waiting on a DREP,
send one so that it can complete its disconnection.
This fixes an issue in iMPI where one side of a connection
ends up waiting up to two minutes on disconnection.
Sean Hefty [Thu, 23 Sep 2010 19:25:29 +0000 (12:25 -0700)]
ibal: send drep in response to unmatched dreq
If a DREQ is received that cannot be matched with an
existing CEP, issue a DREP in response. It's possible
that the targetted CEP issued a DREP which was lost.
The CEP then transitioned through the timewait state
before another DREQ was received, and is no longer accessible.
To prevent the remote side from timing out waiting on a DREP,
send one so that it can complete its disconnection.
This fixes an issue in iMPI where one side of a connection
ends up waiting up to two minutes on disconnection.
projects / ~shefty / rdma-win.git / log