[lkml]   [2010]   [Mar]   [24]   [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:36 PM, Chris Friesen <> 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.

    -- 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-24 20:57    [W:0.021 / U:5.548 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site