Hi Sean- On Jun 20, 2014, at 3:41 PM, Hefty, Sean <sean.he...@intel.com> wrote:
>> I'm considering a change to xprtrdma that would re-use the QP and >> rdma_cm_id after a transport disconnect. >> >> I use rdma_disconnect() and then wait for the TIMEWAIT_EXIT upcall. >> But after that, rdma_resolve_addr() always fails (-EINVAL). >> >> What does xprtrdma need to do to get the rdma_cm_id back to the >> RDMA_CM_IDLE state so I can reset the QP? > > I don't know that the kernel rdma cm code supports this. It's likely that > the id would need to have its state reset and data structures cleaned up. > That said, I doubt re-use of the rdma_cm_id would provide any real advantage. During a remote transport disconnect, the QP leaves RTS. xprtrdma deals with this in a separate transport connect worker process, where it creates a new id and qp, and replaces the existing id and qp. Unfortunately there are parts of xprtrdma (namely FRMR deregistration) that are not easy to serialize with this reconnect logic. Re-using the QP would mean no serialization would be needed between transport reconnect and FRMR deregistration. If QP re-use is not supported, though, it’s not worth considering any further. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
