Messages in this thread | | | Date | Wed, 3 Mar 1999 13:38:37 -0800 (PST) | From | Zach Brown <> | Subject | Re: OSDI paper - IO-Lite: A Unified I/O Buffering and Caching System |
| |
On Wed, 3 Mar 1999, Alan Cox wrote:
[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/
| |