[lkml]   [2010]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: behavior of recvmmsg() on blocking sockets
On Wed, Mar 24, 2010 at 2:55 PM, Brandon Black <> wrote:
> On Wed, Mar 24, 2010 at 2:36 PM, Chris Friesen <> wrote:
>> Consider the case where you want to do some other useful work in
>> addition to running your network server.  Every cpu cycle spent on the
>> network server is robbed from the other work.  In this scenario you want
>> to handle packets as efficiently as possible, so the timeout-based
>> behaviour is better since it is more likely to give you multiple packets
>> per syscall.
> That's a good point, I tend to tunnelvision on the dedicated server
> scenario.  I should probably have a user-level option for
> timeout-based operation as well, since the decision here gets to the
> systems admin/engineering level and will be situational.

I've been playing with the timeout argument to recvmmsg as well now,
and I'm struggling to see how one would ever use it correctly with the
current implementation. It seems to rely on the assumption of a
never-ending stream of tightly-spaced input packets? It seems like it
was meant for usage on blocking sockets. Given a blocking socket with
timeout 0 (infinite), and a recvmmsg timeout of 100us, if you had a
very steady stream of input packets, it recvmmsg would pull in all of
them that it could within a max timeframe of (100us +
time_to_execute_one_recvmsg). However, any disruption to the input
stream for a time-window of N would result in delaying some
already-received packets by N. For example, consider the case that 2
packets are already queued when you invoke recvmmsg(), but then the
next packet doesn't arrive for another 300ms. In this scenario, you'd
end up with recvmmsg() blocking for 300ms and then returning all 3
packets, two of which have been delayed way beyond the specified

-- Brandon
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2010-03-27 14:21    [W:0.063 / U:1.716 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site