[openib-general] [PATCH] [RFC] RDMA generic CMA updates

[Sean Hefty]

James Lentini wrote:
> Why would this module be a ULP and not part of the core? Especially 
> since the rdma_cma.h include file is intended for the core include 
> area, include/rdma. 

It can be a separately loaded module, so a ULP from the viewpoint of verbs, SA 
query, IB CM, etc.

> I expect that the IB_CM_REQ_RECEIVED callback will be confusing to 
> ULPs. The ULP will receive a new cma_id with an old context value. If 
> the ULP wanted to make an adjustments to the cma_id that received the 
> request, it would need to store a reference to it in the old cma_id's 
> context value. I suggest you make the new cma_id part of the event 
> data (see patch below).

The new cma_id must be used after the REQ is received, so I wanted to make that 
clear.  There's not much that a user can do with the listening cma_id from 
within the callback; since it cannot be destroyed from the callback itself. 
This is a fairly minor issue that we can discuss more.

> How will the IP address and port number in the connection request be 
> delivered to the ULP?

The cma_id contains the source and destination address.  See cma_req_recv(). 
This was added in after the initial posting of the code.

> Would the design be cleaner if instead of sprinkling the code with "switch 
> (cma_id->device->node_type)" statements, we used function pointers?

I wasn't sure what the iWarp portion of the code would look like, but I wanted 
to leave place for an iWarp implementation to be easily inserted.  It seems that 
it would take a fair deal of additional code to use function pointers.

> Here's a patch that: 
> 
> - move listen declaration closer to accept and reject
> - add private data and new cma_id fields to event structure
> - record need to address information in the event structure
> - implement private data handling for IB_CM_REQ_RECEIVED and 
>   IB_CM_REP_RECEIVED
> - on white space fix for rdma_cma_reject

Thanks - I'll look it over and merge in the changes.

- Sean