>>Which of the features would you want to see in librdmacm? I guess the >>integration of the cm_id and qp as well as the simpler (synchronous) >connection >>establishment and teardown functionality would fit. However, all cm events >>will thereafter be handled within the library rather than being presented to >>the user. Does that make sense?
I have some ideas for simplifying connection establishment as part of my changes to support native IB addresses through the rdma_cm interface. This includes adding new calls to the librdmacm: rdma_getaddrinfo and rdma_create_id_and_optional_qp_and_bind_addr_and_set_route. I'll pick a different name for the latter. :) Combined, I think these calls could allow a user to more easily connect, while still providing low level control for anyone who wants it. I haven't looked at the details for this, but we may be able to support synchronous operation by allowing the user to provide a NULL rdma_event_channel when creating the rdma_cm_id. We can take advantage of rdma_migrate_id to implement this, or even toggle between synchronous and asynchronous mode. The hope is that the librdmacm can remain threadless. If you can give me a month or so to finish my current patches, I'll take a look at this as part of my work. - Sean -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
