[ofw] [PATCH 3/7] ib/cm: export CM only interface

[Fab Tillier]

>>  Note that you could config the CEP and call kal_cep_pre_rep without
>> the QP's lock, and then perform the checks in the success case and then
>> perform the CID checks and make the assignment.  You can probably do
>> this in other places too in order to avoid holding the lock over the
> CEP calls.
>
> I considered this, but I'm not sure it works.  A call to
> kal_config_cep sets a callback that ends up releasing a reference to
> the QP.  I want to lock around verifying that it's okay to associate
> the CID with the QP and forming that association.  It's not clear to
> me what happens if this is not done atomically.

You shouldn't have a problem here, and here's why:

1. the callback is deref_al_obj
2. you take a reference if kal_config_cep succeeds
3. you're in the IOCTL handler which has a ref

You could have many CEPs with a single QP as 'context', and as long as each CEP 'holds' a reference on the QP you're fine.

>>> The other area of the code that I would like to cleanup is getting
>>> callers to invoke al_destroy_cep() only once for a given CID.  But
>>> this looks much more difficult to achieve.
>>  I think if you manage the QP's CID assignment at a higher level you
>> can do all the necessary checks on the CID before calling destroy, so
>> only one call path should end up calling it.
>
> Ok - it requires a lot more work to achieve.  :)

So you're not planning on providing synchronization for destruction?

> If we can get users above the new interface, then the CEP code could
> be modified to take pointers in place of IDs, which could then be used
> to replace global locking with per CEP object locks.  I think this is
> a longer term goal.

You'll need to also add handle management in the upper layers to manager user-mode clients and add reference counting on the objects referenced by the handles.  I don't think the lookups or the locking is liming connection rates.

-Fab