[PATCH WIP/RFC 6/6] nvme-rdma: keep a cm_id around during reconnect to get events

Steve Wise swise at opengridcomputing.com
Fri Aug 26 07:48:39 PDT 2016


> 
> On Fri, Aug 26, 2016 at 06:52:59AM -0700, Steve Wise wrote:
> > This patch adds the concept of an "unplug" cm_id for each nvme_rdma_ctrl
> > controller.  When the controller is first created and the admin qp
> > is connected to the target, the unplug_cm_id is created and address
> > resolution is done on it to bind it to the same device that the admin QP
> > is bound to.   This unplug_cm_id remains across any/all kato recovery and
> > thus will always be available for DEVICE_REMOVAL events.  This simplifies
> > the unplug handler because the cm_id isn't associated with any of the IO
> > queues nor the admin queue.  Plus it ensures a cm_id is always available
> > per controller to get the DEVICE_REMOVAL event.
> 
> I'll need some time to digest all the crazy RDMA/CM interactions here.
> Do you have any clue how other drivers handle this situation?

No.   I'm not sure the other users correctly handle device removal.   There is
another way though:  I sent out a patch earlier using the ib_client interface to
handle this.  ib_clients register with the ib core and provide add and remove
callback functions to handle device insertion/removal.  We could use that here
instead.   But the vision of the RDMA_CM was to provide a transport-independent
way to handle this I guess...






More information about the Linux-nvme mailing list