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