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. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
