lkml.org 
[lkml]   [2010]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: behavior of recvmmsg() on blocking sockets
From
On Wed, Mar 24, 2010 at 2:36 PM, Chris Friesen <cfriesen@nortel.com> wrote:
> Note that I said "large numbers of sockets".  Like tens of thousands.
> In addition to context switch overhead this can also lead to issues with
> memory consumption due to stack frames.

Ok, agreed there. In my case though, there will only ever be a
handful of sockets. Ideally it would be just one socket. The only
reason I allocate multiple sockets and spawn threads for them is
because you can't scale past one CPU core on a single socket, due to
the NIC and/or the driver and/or the socket locks and/or the basic
nature of the problem.

> 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.

Thanks,
-- Brandon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2010-03-24 20:57    [from the cache]
©2003-2011 Jasper Spaans