[openib-general] CM header file

[Sean Hefty]

frank zago wrote:

>> I was trying to match the existing MAD API.  The CM would perform 
>> timeouts, but not retries.  Consumers could retry request immediately 
>> upon notification of a timeout.  This lets the client change the 
>> timeout value.  (I'm negotiable on this, but the cost of having 
>> clients initiate retries is basically one function call.)
>>
>> I have given some thought to how retries should work.  I've thought 
>> about adding a new call, ib_retry_cm_send() - or something like that, 
>> that resends the last message sent.  Or the callback could indicate to 
>> retry.
> 
> I have the same problem here than with the handler. A client should be 
> able to set timeouts and retries, and let CM take care of the painful 
> stuff.
> The complexity should be in the CM, not repeated amongst the clients.

I am trying to avoid adding policy or hard-coding default values into 
the CM, and follow the same design decisions that we used with the 
current APIs.  Long term I think simpler interfaces will be a better 
solution.

Areas where the majority of clients will need to implement the exact 
same code make sense to push into the CM.  So far there doesn't seem to 
be any disagreement that the CM has features that it doesn't need.  And 
the list of desired features seem to be:

* Perform QP transitions for the user.
* Provide default values when establishing a connection.
* Perform retransmissions.
* Destroy connection identifiers from/after a callback.

Are there others?

- Sean