Date: Thu, 20 Jul 2006 11:21:52 -0700 From: Julian Elischer <julian@elischer.org> To: Jack Vogel <jfvogel@gmail.com> Cc: Mikhail Teterin <mi+mx@aldan.algebra.com>, "David G. Lawrence" <dg@dglawrence.com>, net@freebsd.org Subject: Re: complement to sendfile()? Message-ID: <44BFC9C0.6030606@elischer.org> In-Reply-To: <2a41acea0607201111x84c4ef8jf8cdb50d3ffa28e0@mail.gmail.com> References: <200607192230.14939.mi%2Bmx@aldan.algebra.com> <20060720025003.GF924@tnn.dglawrence.com> <44BFB667.60106@elischer.org> <2a41acea0607201111x84c4ef8jf8cdb50d3ffa28e0@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jack Vogel wrote: > We, myself and Prafulla Deuskar at Intel LAD, have a driver and stack > changes that support Intel's new I/OAT DMA hardware. This is a > DMA engine in the chipset. shades of the old PC with the built in DMA on hte motherboard.... :-) > There is potential to use the hardware > in a number of ways, what we have right now is a receive-side > async dma assist from tcp_input() to soreceive(). The engine > copies from the mbufs direct to user buffers asynchronously, > and only requires the client process to be woken when its > buffers are full. The stack changes to support this are relatively > small, mainly we need to pin user buffers and provide a pointer > down to the stack in order to process them, and of course the > core driver for the engine. > > Similar work was done for Linux and is in the 2.6.18 kernel. > > We see as much as a 20% improvement in CPU utilization > when doing a sustained iperf test. > > We are hoping to get this code into CURRENT soon if there > is interest. > > Cheers, > > Jack > > > > On 7/20/06, Julian Elischer <julian@elischer.org> wrote: > >> David G. Lawrence wrote: >> >> >>Hello! >> >> >> >>My program receives data from the socket and writes it to a file -- >> with the >> >>usual read()/write() tedium. >> >> >> >>Is there anything zero-copying like sendfile() for the socket->file >> direction? >> >> >> >>In fact, sendfile's API may allow to use it in any direction, but >> the manual >> >>is quite explicit, that the second (destination) argument must be >> socket. >> >> >> >>recvfile()? Thanks! >> >> >> >> >> > >> > sendfile() could be extended to allow arbitrary file descriptor >> types as >> >the source and destination, but the zero-copy nature of it can only >> work >> >in the file to socket direction. This is because network buffers can >> be made >> >out of filesystem buffers (file->network direction), but for the >> network to >> >file direction network packets arrive non-deterministically. With >> the right >> >network hardware it would in theory be possible to have the TCP code >> run >> >on the network card and it could DMA the TCP stream directly into file >> >buffers. If pigs had wings, they could fly. :-) >> > >> > >> >> >> We used to do something like this in BSD4.3 (not FreeBSD 4.3) in 1991, >> but we used >> a propriatary filesystem and a proprietary protocol that knew each >> other's data types. >> >> >-DG >> > >> >David G. Lawrence >> >President >> >Download Technologies, Inc. - http://www.downloadtech.com - (866) >> 399 8500 >> >The FreeBSD Project - http://www.freebsd.org >> >Pave the road of life with opportunities. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44BFC9C0.6030606>