[openib-general] Re: ibv_get_async_event

Roland Dreier rolandd at cisco.com
Tue Sep 6 14:40:45 PDT 2005


    Caitlin> I'm not sure I follow the rationale as to why acking is
    Caitlin> needed.  You're requiring a solution to a problem that
    Caitlin> most apps and most devices do not have.

I think you're getting confused between polling a CQ for work
completions, and receiving a completion notification event.  We're
talking about the second one here.

The race condition that exists is device independent.  Any application
that reads completion events in one thread and destroys CQs in another
thread is susceptible.  I believe this includes every application that
uses uDAPL.

    Caitlin> But anyway, if you *do* have an acked cq reap, you should
    Caitlin> take advantage of it by having the cq_poll return a
    Caitlin> *pointer* to the work completion rather than copying it
    Caitlin> to a supplied buffer. This avoids an unecessary copy
    Caitlin> whenever the work completion will be processed
    Caitlin> immediately or transformed into another format (which,
    Caitlin> between them, I believe account for most applications).

Once again -- we're talking about completion notification events, not
polling a CQ for work completions.  But if we were polling for work
completions, I don't see why this is an improvement.  A device driver
can already write the work completion directly into the supplied
buffer as it converts it from hardware format.  This avoids having to
allocate memory in the fast path, and makes it easy to implement
polling multiple work completions in a single call (which is useful
for amortizing locking).

 - R.



More information about the general mailing list