[openib-general] Re: [PATCH] [CMA] RDMA CM abstraction module

[Sean Hefty]

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