> 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 RTR and not RTS?) as for the twice case, still the IB CM > will go through the timewait status in return for the 1st, not bogus > call, correct?
rdma_disconnect() returns the value from modifying the QP state into error. It masks the return value of calling the ib_cm to send the DREQ or DREP. If rdma_disconnect() succeeds, a timewait event should occur, unless the app calls rdma_disconnect() without being connected. Calling disconnect is one way that a QP may be transitioned into timewait. The ib_cm will also transition to timewait in certain connection failure cases: REP times out or is rejected, or remote side detects a stale connection. Without reading through the code, I don't know off the top of my head if a timewait event would follow an asynchronous rdma_connect() failure, even if rdma_disconnect() were called after the error. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
