Jeff Garzik wrote:
Key point 1:
Van's slides align closely with the design that I was already working
on, for zero-copy RX.
To have a fully async, zero copy network receive, POSIX read(2) is
inadequate.
Is there an aio_read() in POSIX adequate to the task?
One needs a ring buffer, similar in API to the mmap'd
packet socket, where you can queue a whole bunch of reads. Van's design
seems similar to this.
Key point 2:
Once the kernel gets enough info to determine which channel should
receive a packet, it's done. Van pushes TCP/IP receive processing into
the userland app, which is quite an idea. This pushes work out of the
kernel and into the app, which in turn, increases the amount of work
that can be performed in parallel on multiple cpus/cores.
Increased opportunity for parallelism is indeed goodness.
Are you speaking strictly in the context of a single TCP connection, or for
multiple TCP connections? For the latter getting out of the kernel isn't a
priori a requirement. Actually, I'm not even sure it is a priori a requirement
for the former?
This also has the side effect of making TOE
look even more like an inferior solution... Van's design is far more
scalable than TOE.
I'm not disagreeing, but it would be good to further define the axis for
scalability.
rick jones
-
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
