[openib-general] [PATCH] initial CM module

[frank zago]

Sean Hefty wrote:

> Libor Michalek wrote:
>
>>   This ties into what I was saying about an error return value from the
>> consumer callback being treated as a connection handle destroy request.
>> There were three return types supported:
>
>
> I'm not opposed to this.  I just haven't thought about it enough.
>
>>   error   - connection handle destroy request
>>   defer   - CM requires an API call to continue. (e.g. REQ callback
>>             requires a send_rep() call to continue) What the Sean's
>>             API does by default.
>>   success - CM generates callback response. (e.g. REQ callback completed
>>             successfully so the CM generates a REP response.)
>>
>>   However, I'm not sure that not having this ability is that big of a
>> code bloat, since you will call the corresponsing API function from
>> the callback, and presumably set similar parameters for the API call
>> as you would set for the callback return parameters. The bigger increase
>> in consumer line count is having each consumer perform the QP state
>> transitions.
>
>
> I agree.  I'm not sure that success is needed.  This adds several 
> parameters that need to be returned from the callback to save a single 
> function call.

It doesn't just save a function call.
For instance:

cm_handler(cm_id, event, param)
{
...
    case CM_REQ:
      if (not yet connected) {
        param.req.userdata[0]=0x5A;
        param.req.userdatalen=1;
        ret = OK;
     } else {
        ret = REJECT;
     }   
....
}

Here, CM has prepared with defaults values the userdata that the handler 
can override.
It hides CM internals: no allocation of a REQ structure, no cleaning of 
structures, no sending of mads.

Frank.