[openib-general] design for communication established affiliated asynchronous event handling

[Or Gerlitz]

Sean Hefty wrote:
> Rimmer, Todd wrote:
>> The CM would open the CA, provide its async event callback routine and
>> perform a special register_cm() verbs call.  Of course most CM traffic
>> would occur on the GSI QP, so this open CA instance was only for this
>> purpose.  This special verb was only available in kernel space (avoiding
>> security issue of application stealing CM interface and because our CM
>> was in the kernel anyway).
> 
> Thanks for the info.  I'm considering this sort of approach.

OK, so you opt for a change that will have the whole solution running 
within the ibstack core (hw driver / core / cm) - the CM gets an async 
event which make it synthesize an RTU and act on it.

So we went down from CMA level handling to CM level handling and it
would work for both user and kernel consumers, this is in the price of 
having to change the verbs access layer for the CM to register on QP 
async events.

Again, also with this solution the ULP has to be aware for CQ 
completions related to a QP on which ESTABLISHED event was not yet 
delivered on the associated CMA ID.

Sound good, in fact our gen1 stack was using this solution as well, 
relying on the VAPI driver feature of delivering affiliated async events 
to all the kernel consumers (the async event ***handler*** was not 
associated with a specific QP)

Or.