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

[Sean Hefty]

>> 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.

This sounds like it would work.  I'll move the QP locking so that the QP and CEP
mgr locks don't need to nest.

>>>> 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?

I don't think that there's an issue with the current code.

I was just saying that the code allows calling al_destroy_cep() multiple times
and the CEP manager does lookups in all calls.  If the code can evolve to where
al_destroy_cep() is only ever called from one place, then there are
optimizations that can be made to remove/optimize locking and avoid lookups.

- Sean