Tom Tucker wrote:
At first blush, the API looks good to me. The kinds of changes I was
pondering were related to hiding some of the routing issues. For
example, if the app. doesn't bind the rdma_cm_id prior to calling
rdma_connect, the code will lookup and use the default route instead of
returning -EINVAL.
From an app's perspective, they need to perform the following on the client
side:
rdma_create_id();
rdma_resolve_addr();
rdma_create_qp();
rdma_resolve_route();
rdma_connect();
Before rdma_resolve_addr() is called, the rdma_cm_id is not associated with a
local device. So, rdma_resolve_addr() must be called before a QP can be allocated.
I had planned on making rdma_resolve_route() optional, but it complicates device
removal handling. It can still be done, but only saves the client about 2 lines
of code.
Note that both rdma_resolve_addr() and rdma_resolve_route() are asynchronous
for IB.
I was planning to do a patch and submit it for review, but if you'd
prefer talking through it -- that's fine
Either will work. I can accept a patch or modify the CMA directly if it's a
fairly straightforward change.
- 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
