>I understand that, however, currently the code I am working with (iser) >wait to get both flushes on all the posted work requests AND disconnect >or address-change event to mark the <rdmacm id, qp> couple as >disconnected, clear it up and signal higher level to reconnect. I'll >have to look what is the way to go for fast reconnection, maybe connect >a new <id, qp> couple before the current one is totally >flushed/disconnected. Also, destroying the ID doesn't remove the qpn >from the IB CM timewait database, correct? hence if I don't wait long >enough and the driver/hw reuses the qpn short enough to hit the IB CM >stale connection/etc logic, I will not be able to reconnect, I guess.
It's the remote side that may be the problem. In general, there's no guarantee that the remote side has exited timewait, which is what you really need to know, or is even aware that the previous connection is no longer in use. - Sean -- 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
