Michael S. Tsirkin wrote:
Any objection to rdma_socket?
Fine with me, this makes the intent of bind/listen explicit.
I have rdma_cm_id right now, and will likely just keep it as that.
+int rdma_resolve_route(struct rdma_id *id, int timeout_ms);
I was trying to say, why doesnt rdma_connect just do this
transparently? Why do we need a separate call?
Eventually rdma_connect will call this for the user if a route hasn't been
resolved. At some point though, the API will likely need to be expanded to
specify some sort of quality of service.
I thought that would also happen at connect time. No?
I went with the option of exposing the necessary functionality. Folding this
into the connect call means that the user cannot view the returned route before
deciding to establishing a connection, and the CMA sets the timeout/retry policy
for resolving routes. The only benefit of hiding this call is a slight code
simplification for the user:
case RDMA_CM_EVENT_ADDR_RESOLVED:
ret = rdma_resolve_route(cma_id->context, timeout);
if (ret)
connect_error();
break;
case RDMA_CM_EVENT_ROUTE_RESOLVED:
connect(cma_id->context);
break;
becomes:
case RDMA_CM_EVENT_ADDR_RESOLVED:
connect(cma_id->context);
break;
To make the API slightly easier to use, I thought of letting
rdma_resolve_route() be optional. But, that makes it more difficult to handle
device removal, and I'm not sure that it's even worth it.
As for QoS, I'm not even sure that it shouldn't be specified when performing the
address resolution, so that the correct device can be selected.
- 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
