[openib-general] CM header file

[Sean Hefty]

Libor Michalek wrote:

>   The other option is to destroy the connection if the consumer returns
> an error value from the callback.

I'll have to think about this.  As a personal preference I try to avoid 
having callbacks return values.  But then I'm not thrilled about 
passing in flags to destroy to handle this either.

> Along the same lines, will the 
> consumer be allowed to call the corresponding response function from
> a callback? (e.g. ib_send_cm_rep() from the REQ callback) If not then
> the same behaviour could also be achieved with a callback return value.

This is a goal of the implementation, and I don't foresee any reason 
why it can't be done.

>>* Should listening clients call an "accept" routine to wait for a 
>>  connection request?  Currently, the API operates asynchronously and 
>>  inokves a CM event handler.
> 
>   I don't think this is necessary. Presumably the biggest reason to use
> "accept" is to force the consumer to use its own thread to handle CM state
> changes, thus avoiding CM or MAD thread deadlock if there is a buggy
> consumer, or is there another reason to add this step?

I didn't think it was necessary either, but wanted to mention it as a 
possible idea.

>    However, a nice to have feature which I've grown use to is the ability
> to listen to an entire range of service IDs using a value/mask combo.

I'll add this.  I saw the mask in the Topspin CM API, but didn't look 
into why it was there, so removed it.

Thanks for the feedback.

- Sean