From: "Andrew Grover" <[EMAIL PROTECTED]> Date: Thu, 20 Apr 2006 15:14:15 -0700
> First obviously it's a technology for RX CPU improvement so there's no > benefit on TX workloads. Second it depends on there being buffers to > copy the data into *before* the data arrives. This happens to be the > case for benchmarks like netperf and Chariot, but real apps using > poll/select wouldn't see a benefit, Just laying the cards out here. > BUT we are seeing very good CPU savings on some workloads, so for > those apps (and if select/poll apps could make use of a > yet-to-be-implemented async net interface) it would be a win. > > I don't know what the breakdown is of apps doing blocking reads vs. > waiting, does anyone know? All the bandwidth benchmarks tend to block, real world servers (and most clients to some extent) tend to use non-blocking reads and poll/select except in some very limited cases and designs doing something like 1 thread per connection. This is an issue for the TCP prequeue and as a consequence VJ's net channel ideas. We need something to wakeup some context in order to push channel data. All the net channel stuff really wants is an execution context to run the TCP stack outside of software interrupts. I/O AT wants something similar. For net channels the probably best thing to do is to just queue to the socket's netchannel, and mark poll state appropriately and just wait for the thread to get back into recvmsg() to run the queue. So I think net channels can be handled in all cases and application I/O models. For I/O AT you'd really want to get the DMA engine going as soon as you had those packets, but I do not see a clean and reliable way to determine the target pages before the app gets back to recvmsg(). I/O AT really expects a lot of things to be in place in order for it to function at all. And sadly, that set of requirements isn't actually very common outside of benchmarking tools and a few uncommonly designed servers. Even a web browser does non-blocking reads and poll(). - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
