[describes passing ip csums to the kernel with msgs to be sent out]
> Oh and I suspect its < 100 lines of code to add to the OS. Now that one
> _is_ a win. Consider the high performance ftp server keeping a checksum cache
> of the commonly downloaded files. Zab is going to like this.
caching checksums somewhere could be quite helpful to static file->network
ip transmitting. it would allow us to do zero copy tx on cards that have
reasonable dma properties but who can't do ip csuming. (that is a huge
number of modern pci cards :)). if we had a very clever data structure
full of ranges of files that we've checksumed we could easily build iovecs
with header/data and pass them to scatter gather aware network cards.
[yes, very 2.3.. could tie in nicely with the block cache and sendfile()
initially]. In a monster static content server this just might be worth
the memory used to decrease the cpu resources consumed per transfer. As
andi pointed out, it might be interesting to store udp csums to speed up
nfs in a similar fashion.
but handling the csum cache in userland seems like it wouldn't be terribly
useful. you'd have to guess packet sizes and deal with mtu changes mid
connection and can't simply block on sendfile()-like functions to send
things out, etc.
as for the cgi->server ipc case, I'm with alan. its dynamic so caching
doesn't matter; just toss it right to the client, right? in hftpd for
site exec we simply dup the control channel and hand it as stdout to the
new process. no context switches reading/writing, no wasted mem bw
shipping data through the client's server thread. with tcp_cork we also
send out nice maximally efficient packets as well.
-- zach
- - - - - -
007 373 5963
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/