Date: Thu, 20 Jul 2006 11:11:44 -0700 From: "Jack Vogel" <jfvogel@gmail.com> To: "Julian Elischer" <julian@elischer.org> Cc: Mikhail Teterin <mi+mx@aldan.algebra.com>, jfvogel@gmail.com, "David G. Lawrence" <dg@dglawrence.com>, net@freebsd.org Subject: Re: complement to sendfile()? Message-ID: <2a41acea0607201111x84c4ef8jf8cdb50d3ffa28e0@mail.gmail.com> In-Reply-To: <44BFB667.60106@elischer.org> References: <200607192230.14939.mi%2Bmx@aldan.algebra.com> <20060720025003.GF924@tnn.dglawrence.com> <44BFB667.60106@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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?2a41acea0607201111x84c4ef8jf8cdb50d3ffa28e0>