From owner-freebsd-hackers Sat Nov 18 17:24:39 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id E42AC37B479 for ; Sat, 18 Nov 2000 17:24:36 -0800 (PST) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id RAA06983; Sat, 18 Nov 2000 17:23:32 -0800 (PST) Message-Id: <200011190123.RAA06983@implode.root.com> To: Jin Guojun (DSD staff) Cc: bmilekic@dsuper.net, hackers@FreeBSD.ORG Subject: Re: sendfile for raw disk (was: zero copy TCP) In-reply-to: Your message of "Sat, 18 Nov 2000 16:31:11 PST." <200011190031.eAJ0VBo29408@portnoy.lbl.gov> From: David Greenman Reply-To: dg@root.com Date: Sat, 18 Nov 2000 17:23:31 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> > Both, but I may do either way, depending on which way is easier. >> > If we can directly DMA from a disk drive to a NIC, that will be great. >> > If the current implementation requires preloaded buffer, that works. >> > So, where can I look for the patch? >> > >> >> Please see sendfile(2). > >It seems that sendfile(2) can read only a regular file. I wiould like to >modify it to send a raw disk block. >Before going for it, I would like to know what was the reason for not doing >this, and what may be the issus for doing this? The main issue is that sendfile() is very much VM-system centric in the way that it implements zero-copy sends. In order for raw devices to work, you would need to have a raw device vm_object to hold the pages. The problem with this is that it creates cache coherency problems with any cached file data. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message