Re: how to preserve QP over HA events for librdmacm applications

On Sep 19, 2012, at 2:14 PM, "Atchley, Scott" [off-list ref] wrote:

On Sep 19, 2012, at 1:05 PM, "Hefty, Sean" [off-list ref] wrote:

quoted

quoted

I too would be interested in bringing a QP from error back to a usable state. I
have been debating whether to reconnect using the current RDMA calls versus
trying to transition the existing RC QP.

I assumed to transition the existing QP that I would need to open a socket to
coordinate the two sides. Is that correct?

If I were instead to use rdma_connect(), does it require a new CM id or just a
new QP within the same id?

What do you gain by transitioning an RC QP from error to RTS, versus just establishing a new connection?

I have a certain amount of state regarding a peer. I lookup that state based on the qp_num returned within a work completion, for example. If I reconnect, I will need to migrate the state from the old qp_num to the new qp_num.

I have no preference which is why I asked about the two options (opening a socket to coordinate state transitions versus connecting with a new QP).

I don't know if it matters to the conversation or not, but I use an SRQ. I am unclear how to remove a QP from the SRQ. Is ibv_destroy_qp() sufficient? Or do I need to use rdma_destroy_qp()?

I basically, use the rdma_* calls for connection setup. After that, I use only ibv_* calls for communication (Send/Recv and RDMA).

Scott--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html