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. 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. The overall
bottleneck in the kernel is reduced. PCI MSI-X further reduces the
bottleneck, after that. 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.
So, I am not concerned with slideware. These are two good ideas that
are worth pursuing, even if Van produces zero additional output.
Jeff
-
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
