[openib-general] Proposed device enumeration & async event APIs
Roland Dreier
roland at topspin.com
Mon Sep 13 20:41:20 PDT 2004
Hal> Is there a way to do the following things:
Hal> 1. Can other than the QP owner obtain any QP async events (or
Hal> perhaps only certain ones) ? Certain events might need to go
Hal> to more than 1 place (I think that 2 is sufficient).
Hal> (perhaps this is a second event handler which could be at
Hal> qp_create time or qp modify time (with a new virtual QP
Hal> attribute to add or remove this).
Hal> 2. An optimization would be to be able to obtain all QP async
Hal> events rather than needing to do this for all QPs as they
Hal> come and go. Perhaps something like
Hal> ib_set/clear_global_qp_handler() would set/clear the second
Hal> event handler in all existing QPs and if a global handler is
Hal> set, this would be used at QP create time.
No, there is not a way to do what you ask at the moment. I assume
that your motivation is the CM, specifically for communication
established and path migrated events. With that perspective, #2 is
not that useful because it means that the CM needs to keep yet another
table mapping local QP to CM context, which is a hassle and a
potential performance hit.
#1 is somewhat suboptimial as well, because there is no ordering
between when the CM might process a communication established event
and when the client might receive the actual receive completion. I
think we've found that it's actually easier for the CM client to
explicitly synchronize with the CM by calling into the CM when it gets
an event prior to the CM entering the established state (rather than
trying to drive the CM via async events).
With all that said, I'm not that opposed to implementing 1 or 2 as
appropriate, but I would like to see a consumer of the API that shows
a real benefit before going either of those two ways.
- R.
More information about the general
mailing list