ffed1f67   
   From: grahn+nntp@snipabacken.se   
      
   On Sat, 2010-03-13, David Schwartz wrote:   
   > On Mar 13, 12:23 am, Jorgen Grahn  wrote:   
   >   
   >> Fine, but this has a select setup + wakeup + read overhead for every   
   >> single UDP datagram.  I could use the Linux epoll interface, but that   
   >> would only optimize the select setup part.   
   >   
   > If you're dealing with even a moderate number of sockets, and the   
   > typical case is when few of those sockets are heavily active, the work   
   > the kernel has to do on each entry and exit into 'select' is pretty   
   > large. This overhead is removed with epoll.   
      
   Yes, I have personally seen be a problem (on Linux, with a few dozen   
   UDP sockets).  And I have seen your earlier postings on this. Doesn't   
   hurt to repeat it, though.   
      
   ...   
   >> Another option is (B) nonblocking UDP sockets. Select as before, but   
   >> instead of reading once, read and process until EAGAIN.  If I have a   
   >> growing Rx queue on the socket this should be better ... but on the   
   >> other hand if I'm faster than the UDP sender this means I call   
   >> recvmsg() twice for each UDP message.   
   >   
   > It won't matter, because you just called 'recvmsg' on the same socket.   
   > Everything will be warm in the cache. The second 'recvmsg' call, if   
   > and only if you are so caught up that you get back there before   
   > another packet is received, won't really matter.   
   >   
   > It's nut to not be worried about 'select' overhead but to be worried   
   > about an extra 'recvmsg' call. (Assuming you have other sockets to   
   > 'select' on too, at least.)   
      
   I never said I wasn't worried about select() overhead. But perhaps I   
   overstimate the cost of a system call (recvmsg() on an empty socket,   
   and as you say with a warm cache).   
      
   >> A third option (C) is a thread for each UDP socket which just blocks   
   >> in a recvmsg() loop.  But I don't want threads.   
   >   
   > If you have only a very small number of important UDP sockets, this is   
   > likely your best bet.   
      
   OK. So you're saying the people who don't want threads are likely to   
   do (B), then?   
      
   I *did* check the bind9 sources, but they used Paul Vixie's eventlib   
   which I'm sure is great for these kinds of things, but made it hard to   
   quickly see what was going on.   
      
   >>   I'm beginning to dislike UDP for this reason too -- does anyone   
   >>   agree with me?  With TCP you can wake up and consume a huge chunk of   
   >>   data if you have a huge userspace buffer to read into. With UDP all   
   >>   you get is one datagram.   
   >   
   > That's not a fair comparison. With TCP, if you're caught up and have   
   > CPU to spare, you will wind up reading only one packet's worth of   
   > received data anyway. With UDP if you fall behind, you can read as   
   > many datagrams as you want in a fast loop.   
   >   
   >>  Maybe there should be a variation of   
   >>  recv/readv/etc which lets you provide buffer space for many   
   >>  datagrams (and their source addresses).   
   >   
   > To do what? Reduce user/kernel transitions in the least expensive case   
   > where you immediately 'recvmsg' on the same socket? I don't think the   
   > optimization would be significant.   
      
   Yes, my whole reasoning what based on the assumption that system calls   
   are expensive, and the observation that the syscall rate grows when   
   the UDP read load increases, but not so in the TCP case.   
      
   I don't really know if they *are* expensive -- on my target system and   
   on Unix in general.   
      
   /Jorgen   
      
   --   
     // Jorgen Grahn    O  o   .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)