From: "Chris Leech" <[EMAIL PROTECTED]> Date: Thu, 16 Mar 2006 11:24:05 -0800
> > Thanks, that clarifies things. So, if I've understood correctly, the > > benefit kicks in when: > > > > 1) I/OAT is enabled :) > > 2) The user posts a recv() (or the like) of >= 2K > > 3) There is >= 2K of data available to give them > > > > yes? > > Yes 4) the application blocks in recvmsg() I don't like this performance graph at all because it's just some dumb bulk transfer, the client spinning in sendmsg() and the receiver() spinning in recvmsg(). That is not real life. Real life is a server epoll'ing on several thousand sockets and making quick short trips into sendmsg() and recvmsg() as the events make socket space available, as just one example. This pretty graph is a nice thing to show at the Intel Developer Forum to get some ooh's and aaah's, but frankly the technical crowd here needs to see something much more comprehensive. One thing that might be the case is that a web server might perform better with I/O AT _disabled_ even for >2K transfers because the latency back to userspace matters, and the app performs better if we just do the memcpy() rather than block on the DMA engine operation. Intel has provided no test data showing if that is the case for a highly loaded web server or not, for example. All we have is a bulk transfer graph, and that's only a microscopic look into the effects that I/O AT has on TCP performance. It is my opinion that for such an intrusive change, and given the amount of time this has probably been worked on, a more substantial set of performance metrics need to be provided. Even if you had just provided a bulk transfer and a highly loaded webserver as metrics I would have considered that a reasonable sample of TCP usage. A bulk transfer by itself, very much is not. Scheduling is a big issue for servers processing a lot of connections. Latency can even be more important than throughput, and we need to see what effect I/O AT has in that area before we can seriously consider it for inclusion. - 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
