[openib-general] RFC userspace CMA

[Sean Hefty]

Caitlin Bestler wrote:
>>- 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.
> 
> Why?

If the userspace CMA talks to the kernel CMA, then the kernel CMA cannot 
transition the QP.  There's not even a valid handle.  The alternative is to have 
the userspace CMA talk to userspace IB CM, SQ query, address translation modules.

A user of the kernel CMA can still call rdma_create_qp() and have the kernel CMA 
transition it for them.  The same is true for userspace applications.

> Why does the uCMA need to open HCAs? Why does it have to be
> anything other than a front-end to the kCMA?

The kernel CMA abstracts device addition/removal from the user.  To accomplish 
the same goals with the userspace CMA, the uCMA needs to open/close the device. 
    If the user opens and closes the device, then API changes are necessary.  I 
don't see any benefit for the user to open the device, since it requires users 
to search for devices based on some sort of identifier.

> I can see where a user-mode daemon might get a connection
> request that could only be answered with a QP on an device
> that it had not previolusly opened, and that opening that
> device based on information in the Connection Request would
> be useful -- but that still doesn't have the uCMA opening
> the device. More importantly, the problem can be solved 
> just as easily by having the listener listen only on rdma
> devices that it has already opened.

This results in the listen call operating on an RDMA device, rather than on an 
IP address, which is the intent of the API.

- Sean