People who think that VM games are faster than a simple linked list
need to go out and do the math - it is infinitely more desirable to
do the memory management by hand both from a flexibility AND a
speed standpoint.
I don't think they're needed to give the card memory for incoming
frames. Nearly all such cards allow you to feed them a linked list of
buffers which typically look like this:
buffer 0 HIPPI + IP + TCP headers
buffer 1 First page of data
buffer 2 Second page of data
buffer 3 etc...
Typically the buffer 0 stuff is allocated from a SLAB cache of some
sort, or something like this, so the header buffer is allocated
quickly and in a cache friendly manner (one thing here is that we know
these cache lines will be pulled around between the DMA controller and
the CPU L2 cache, so when we miss we want to only need to bring in the
minimum number of cache lines, SLAB can lay things out so that this is
in fact the case).
The VM tricks _are_ necessary for allowing the non-touching movement
of those pages to/from userspace and the controller (or the page cache
and the controller).
I think VM tricks is too strong a phrase, it just requires a mechanism
to pin down pages. This essentially means:
1) Blast all mappings of this page from userspace, or mark them COW.
2) Mark the page for exclusive access by us until the networking is
done with the page
3) When networking is done, unpin the page and unCOW the page in user
mappings if they have not tried to write to it (and thus now have a
private copy) already
And then you have other schemes, such as under IRIX, where they use
64k page sizes on the larger systems to make this all even faster.
---------------------------------------------////
Yow! 11.26 MB/s remote host TCP bandwidth & ////
199 usec remote TCP latency over 100Mb/s ////
ethernet. Beat that! ////
-----------------------------------------////__________ o
David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><