From owner-freebsd-net Thu Feb 1 11:28:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id C335C37B67D for ; Thu, 1 Feb 2001 11:28:12 -0800 (PST) Received: by overlord.e-gerbil.net (Postfix, from userid 1001) id 6F0A7E4BB9; Thu, 1 Feb 2001 14:28:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by overlord.e-gerbil.net (Postfix) with ESMTP id 52835E4BB8; Thu, 1 Feb 2001 14:28:07 -0500 (EST) Date: Thu, 1 Feb 2001 14:28:07 -0500 (EST) From: "Richard A. Steenbergen" To: David Greenman Cc: bsddiy , freebsd-net@FreeBSD.ORG Subject: Re: sendfile() In-Reply-To: <200102011819.KAA23975@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 1 Feb 2001, David Greenman wrote: > >I don't want to bring flame war, but the following Linus' words may be > >right: > > The FreeBSD API is the way it is after a collaboration with the Apache > folks. The sendfile() implementation in FreeBSD works just fine and I think > it has one of the most complete API's of any of them out there. Sounds like > typical Linus misinformation. > If you have a point to make, then make it. I would be happy to consider > any real shortcomings in sendfile(), but right now I don't know about any. The most serious shortcoming I see is that it still requires a storm of syscalls for async operation. Take this for example, a daemon with 1000 open connections transfering data to dialups. The first pass through, sendfile() will fill the socket buffer and move on to the next fd. Then shortly thereafter, with the sockbuf only slightly drained, new write events will come up in whatever polling method you're using, and you get to fire off another 1000 syscalls just to add an extremely small amount of data. You must also either keep 1000 open fds for the source file, or open() and close() on every pass. You could have your event poller check the status of the sockbuf and make some intelligent determination of when to trigger a new write event, perhaps based on some knowledge of the rate at which the connected peer is draining information. This potentially restricts the amount of data in the snd sockbuf and thus the size of the tcp window which can be fast recovered in the event of packet loss, but if done correctly and with a semi accurate guess at the rate of drain it could be useful. kevent filter? If sendfile() was in effect aio_sendfile(), it would be even more useful. -- Richard A Steenbergen http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message