Re: behavior of recvmmsg() on blocking sockets

[Brandon Black]

On Wed, Mar 24, 2010 at 2:36 PM, Chris Friesen <cfriesen@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/