From: Rick Jones <[EMAIL PROTECTED]> Date: Wed, 01 Feb 2006 16:39:00 -0800
> My questions are meant to see if something is even a roadblock in > the first place. Fair enough. > Maybe I'm not sufficiently clued-in, but in broad handwaving terms, > it seems today that all three can be taking place in parallel for a > given TCP connection. The application is doing its > application-level thing on request N on one CPU, while request N+1 > is being processed by TCP on another CPU, while the NIC is DMA'ing > request N+2 into the host. That's not what happens in the Linux TCP stack even today. The bulk of the TCP processing is done in user context via the kernel prequeue. When we get a TCP packet, we simply find the socket and tack on the SKB, then wake up the task. We do none of the TCP packet processing. Once the app wakes up, we do the TCP input path and copy the data directly into user space all in one go. This has several advantages. 1) TCP stack processing is accounted for in the user process 2) ACK emission is done at a rate that matches the load of the system. Ie. ACK goes out as fast as we can context switch to the app receiving the data. This feedback makes all senders to a system send at a rate that system can handle. 3) checksum + copy in parallel into userspace is possible And we've been things like this for 6 years :-) This prequeue is another Van Jacobson idea btw, and net channels just extend this concept further. - 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
