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.
How large is "the bulk?"
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.
Sounds a little like TOPS but with the user context. OK I think I can grasp
that.
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.
ACK emission sounds like something tracked by the EPA :)
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.
Once those senders have filled the TCP windows right?
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.
So the parallelism I gained by moving netperf from the interrupt CPU to the
non-interrupt CPU was strictly between the driver+ip on the interrupt CPU and
tcp+socket on the other right?
Cpu0 : 0.1% us, 0.1% sy, 0.0% ni, 60.1% id, 0.2% wa, 0.5% hi, 39.1% si
Cpu1 : 0.2% us, 20.9% sy, 0.0% ni, 34.2% id, 0.0% wa, 0.0% hi, 44.8% si
(netperf was bound to CPU1, and assuming the top numbers are trustworth)
rick jones
onlist no need to cc
-
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
