[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