[openib-general] CQ peek

Roland Dreier rolandd at cisco.com
Fri Jul 8 15:34:15 PDT 2005


First, a general point about peek CQ.  For all RDMA device
architectures that I know of, doing "peek CQ" is just as expensive as
doing "poll CQ," since the driver needs to do the same locking and
incur the same cache misses either way.  And then the app will always
have to do "poll CQ" later anyway.

    Kevin> Peeks are often used to determine what processing to
    Kevin> perform next in code that doesn't want to do the processing
    Kevin> itself.  A simple example would be if your in a send thread
    Kevin> was sending lots on packets every so often it may peek at a
    Kevin> CQ used for receive completions and if their are receives
    Kevin> ready then either signal the receive thread or just put a
    Kevin> marker on the wall and exit to allow receive processing to
    Kevin> happen. Usually ULP that support polling modes give
    Kevin> priority to receives over sends so peek is an easy way for
    Kevin> the send thread to cool it and switch gears to received.

It seems better to use a completion event on the receive CQ to wake
up the receive thread, or just poll the receive CQ and pass any
completions you find to the receive queue.  Doing a peek in one thread
and a poll in another is almost guaranteed to be terrible for performance.

    Kevin> Peek may also be useful to batch together completion
    Kevin> processing into a bigger therefore potentially more
    Kevin> efficient unit. For example, you have a send fifo where the
    Kevin> completions are steered into a completion queue.  You may
    Kevin> only want to process the send completions after some number
    Kevin> of send fifo slots have completed therefore batching up the
    Kevin> processing into big units.

Again, I think peek is the wrong interface here.  Either continue
polling and accumulating completions until you get the number of
completions you want to batch, or have only every Nth send generate a
completion at all.

    Kevin> My last and least convincing reason for peek is if we want
    Kevin> the gen2 user space libraries to have a broad set of ULP
    Kevin> layer ontop of it.  Some of those ULPs may have implemented
    Kevin> peek in their interface and not having it in the lower
    Kevin> layer makes it difficult.

This is moderately compelling, and if someone has a concrete use for
poll CQ I'll probably end up implementing it someday (unless someone
beats me to it).  But I'd be somewhat surprised if a ULP uses a
primitive that is not defined in either the IB or iWARP verbs.

 - R.



More information about the general mailing list