[ofw] [RFC] ib cm: export CM only interface

[Fab Tillier]

>> At least this area of the code needs work.  I will move iba_cm_id into
>> a larger structure that contains an event that gets signaled by a
>> destroy callback. cm_destroy_id() will wait on that event before
>> freeing p_id.
>>
>> The other place where al_destroy_cep() is called should be fine,
>> since it's inside the callback for the listen.
>
> I also added a wrapper around al_destroy_cep() -- kal_destroy_cep() --
> to allow specifying the destroy callback when, er.., calling destroy!

That's the way it was originally, and there was a race in the CM code where multiple paths might decide to try to destroy the CEP.  In all cases the destroy call took the same callback, but the issue was that if two threads went to destroy a CEP simultaneously, one would succeed and the other would fail.  How do you handle the failure case?  In this particular case the failure is benign.  In a different case where you don't have multiple threads calling destroy, you might want to actually release the reference that you had taken on your object since you won't get a destroy callback that releases it (somehow the CEP is gone already).

How do you distinguish between the two?

The solution was to specify the destroy callback at creation or pre-rep time, so that whenever the CEP was destroyed, through whatever means, the reference taken for it would be released.

> I don't understand how the existing interfaces work if the user
> rejects a REQ, since they can't ever specify the destroy callback.

If they are rejecting the REQ they didn't bind the CEP to a QP - the CEP has no context, and thus holds no reference on that context.  There's no need to have a destroy callback in this case - you destroy the CEP and it goes away.

-Fab