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
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
