On Mon, 8 Jan 2001, Rik van Riel wrote:
> I really think the zerocopy network stuff should be ported to kiobuf
yep, we talked to Stephen Tweedie about this already, but it involves some
changes in kiovec support and we didnt want to touch too much code for
2.4. In any case, the zerocopy code is 'kiovec in spirit' (uses vectors of
struct page *, offset, size entities), so transition to a finalized kiovec
framework (or whatever other mechanizm) is trivial. Right now kiovecs are
*way* too bloated for the purposes of skb fragments.
> The usefulness of the patch you posted is rather .. umm .. limited.
i violently disagree :-) The upcoming TUX release is based on David's and
Alexey's cleaned-up zerocopy framework. [thus TUX and zerocopy are
separated.] David's patch adds a *very* scalable implementation of
zerocopy sendfile() and zerocopy sendmsg(), the panacea of fileserver
(webserver) scalability - it can be used by Apache, Samba and other
fileservers. The new zerocopy networking code DMA-s straight out of the
pagecache, natively supports hardware-checksumming and highmem (64-bit DMA
on 32-bit systems) zerocopy as well and multi-fragment DMA - no
limitations. We can saturate a gigabit link with TCP traffic, at about 20%
CPU usage on a 500 MHz x86 UP system. David and Alexey's patch is cool -
check it out!
> Having proper kiobuf support would make it possible to, for example,
> do zerocopy network->disk data transfers and lots of other things.
i used to think that this is useful, but these days it isnt. It's a waste
of PCI bandwidth resources, and it's much cheaper to keep a cache in RAM
instead of doing direct disk=>network DMA *all the time* some resource is
> Furthermore, by using kiobuf for the network zerocopy stuff there's a
> good chance the networking code will be integrated.
David and Alexey are TCP/IP networking code maintainers. So if you see a
'test this' networking framework patch from them on l-k, it has quite high
chances of being integrated into the networking code :-)