Michael S. Tsirkin wrote:
I was originally thinking along the lines of still using ESTABLISHED, and simply
delaying RTU till after the handler is called. We would then need to teach CMA
to perform reject instead of RTU if handler returns an error code.
We even can have a flag to select the required behaviour, or even
behave specially for SDP, although I don't think this makes a lot of sense.
Sean, what looks best to you?
I need to think about this more. I do think that the current API will work
fine, but would require SDP to manage the QP transitions, which really isn't
that much work. I will need to see what can be done about separating QP
transitions from event reporting, if SDP wants to see all events, but still let
the CMA manage the QP transitions.
There's already specific checking for SDP in the CMA, so extending that doesn't
sound that too bad, (considering the alternative to SDP specific checks is
duplicating functionality).
I don't like the idea of using the return code from the user's handler to send a
reject or RTU when there are API calls that the user could just invoke.
- Sean
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
