[openib-general] Re: RFC userspace CMA

[Michael S. Tsirkin]

Quoting Sean Hefty <mshefty at ichips.intel.com>:
> Subject: RFC userspace CMA
> 
> I'm soliciting any comments that anyone might have on the general design for the 
> userspace CMA before I get too far into the implementation.
> 
> - The API will match the kernel API for the most part.  The exception is that 
> event handling will match other userspace libraries (get/ack event).
> 
> - There will be a single CMA device exported through /sys/class/infiniband.
> 
> - The kernel CMA will be modified to remove the requirement to use 
> rdma_create_qp().  Users that want to allocate and manage their own QP states 
> will be able to specify QP attributes (qpn, qp_type, srq) through the 
> rdma_conn_param structure.
> 
> - The kernel CMA will expose a new call, rdma_init_qp_attr() to initialize QP 
> attributes used to modify the state of the QP.  The call will be similar to the 
> infiniband CM routine.  Use of this call is optional.  The CMA will 
> automatically transition QPs created by rdma_create_qp().
> 
> - The uCMA will open devices for users and return them the device context with 
> related events.  The uCMA will close the device if there are no rdma_cma_id's 
> associated with it.
> 
> - To support device add, the uCMA will need a new verb's call: 
> ibv_open_device_by_guid().  If a connection request occurs for a device that is 
> not yet known by the uCMA, it will open the device.
> 
> Comments?
> 
> - Sean

Sounds like a lot of work :).

Are there benefits to this approach as opposed to implementing everything
in a library on top of ucm/uverbs?

-- 
MST