[openib-general][PATCH][RFC]: CMA IB implementation

[Guy German]

Sean Hefty wrote:
> Guy German wrote:
>> static void cma_route_handler(u64 req_id, void *context, int rec_num)
>> {
>>     status = ib_at_paths_by_route(&cma_ctx->cma_route, 0,
>>                       &cma_ctx->cma_path, 1,
>>                       &cma_ctx->ibat_comp);
>> }
>> int ib_cma_connect(struct ib_cma_conn *cma_conn, void **cma_id)
>> {
>>     status = ib_at_route_by_ip(dst_ip, 0, 0, 0, &cma_ctx->cma_route,
>>                    &cma_ctx->ibat_comp);
>> };
> 
> I still think that it may be better for the user to get the route/path 
> separately from establishing a connection.  This simplifies the internal 
> state handling, and I believe maps better to the user allocating the QP, 
> transitioning it to the INIT state, and pre-posting receive buffers.  An 
> application may want to change its behavior based on its path (such as 
> MTU or data rate). Integrating this in with the connect call requires 
> applications that want to do this to operate with the lower level 
> connection interfaces.

The problems I see with asynchronous route/arp model in the generic cm API is 
that consumers will have to deal with complicated caching (that can be 
implemented in the at module) and that it is not native to iwarp.

What do other people think about it ?

> Also, based on previous discussions, I think that we need to come up 
> with a way to map the destination IP address to a route that doesn't 
> involve ATS.  

This way (ib_at_route_by_ip) doesn't involve ATS, it uses ipoib (when called 
with flag IB_AT_ROUTE_USE_DEFAULTS==0)

> We'll also need to define the best way to store the IP address in the CM 
> private data.  I remember that Yaron and Roland both mentioned methods 
> for doing this, and we may need to make this visible through the API.

OK

Guy