behavior of recvmmsg() on blocking sockets

[Brandon Black <blblack@gmail.com>]

[Not on the list, please CC responses]

Currently, my application code uses blocking UDP sockets and is
basically structured like this:

while(1) {
    recvmsg(fd, ...);
    // do some work on the packet
    sendmsg(fd, ...);
}

It uses a thread-per-socket model, and the "do some work" code is very
fast, and so this turns out to be more efficient than non-blocking
techniques for my use case.  Today I started playing with 2.6.33's new
recvmmsg(), hoping to convert my code like so (still on blocking
sockets):

while(1) {
    recvmmsg(fd, ...);
    // do some work on up to N packets
    // loop over sendmsg() foreach packet to be sent
    //   (or sendmmsg() if/when that interface becomes available)
}

The catch I ran into is that on a blocking socket, recvmmsg() will
block until *all* vlen packets have been received.  The behavior I'd
prefer for my use case would be for it to only block until at least
one packet is available, not until all are available.  Or in code
terms, the first internal call to recvmsg should use the supplied
flags, and the rest of the recvmsg calls should use flags &
MSG_DONTWAIT.  It's not clear to me which is the better default
behavior, but I feel like at the very least there should be a flag
that can switch behavior between the two possible interpretations of
"blocking".

Obviously, I can also work around this at the user level by simply
switching to a non-blocking socket and using select/poll before
recvmmsg, but then under any conditions where only 1 packet is
available (probably fairly common) I'm issuing two syscalls per packet
when only one should be necessary (and only one is necessary when
using recvmsg()).  This seems inefficient and antithetical to one of
the design goals of recvmmsg (cut down the syscalls:packets ratio).

Thoughts on this?

Thanks,
-- Brandon