I'm debugging some disconnect related race in iser - and wanted to check
with you something re the CM/RDMA-CM state machine: I see that when a
disconnected is initiated by the passive side (iser target) of a
connection, such that the active side (iser initiator) gets
On Mon, Nov 14, 2011 at 9:16 PM, Hefty, Sean sean.he...@intel.com wrote:
After disconnecting, the QP should enter the timewait state for twice the
packet lifetime.
Does going through timewait always holds? e.g no matter what's the
return status of rdma_disconnect and/or the status of the
Does going through timewait always holds? e.g no matter what's the
return status of rdma_disconnect and/or the status of the rdma_cm
disconnected event?
It usually holds. It will fail if rdma_disconnect() is called from a bogus
state. But otherwise, I believe that it will enter timewait on
It usually holds. It will fail if rdma_disconnect() is called from a bogus
state. But
otherwise, I believe that it will enter timewait on failure to send or
receive a disconnect
message
mmm, so can these bogus states for rdma_disconnect to be called be
better defined? basically, for the
mmm, so can these bogus states for rdma_disconnect to be called be
better defined? basically, for the case where the rdma_cm manages the
consumer QP, this call is the only way to move an RC QP into the error
state when the QP is okay and the consumer want to flush, etc.
By bogus I mean
By bogus I mean calling disconnect when the QP has never been connected, or
calling
disconnect twice
what return value can serve as bogus indication for the application?
is that -EINVAL? also, basically a QP could have buffers posted to it
also before being connected (e.g after RTR or there's
what return value can serve as bogus indication for the application?
is that -EINVAL? also, basically a QP could have buffers posted to it
also before being connected (e.g after RTR or there's no point in time
an rdma-cm consumer for which the cma manages the QP state is exposed
to such QP in
On Mon, Nov 14, 2011 at 11:55 PM, Hefty, Sean sean.he...@intel.com wrote:
[...] calling disconnect is one way that a QP may be transitioned into
timewait [...]
I was talking on the QP physical state (e.g error that causes
flushes) not the state w.r.t the IB CM.
Or.
--
To unsubscribe from
