On Sep 19, 2012, at 2:14 PM, "Atchley, Scott" <atchle...@ornl.gov> wrote:
> On Sep 19, 2012, at 1:05 PM, "Hefty, Sean" <sean.he...@intel.com> wrote: > >>> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
