From owner-freebsd-net Thu Feb 1 10: 1:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id C3C3937B4EC for ; Thu, 1 Feb 2001 10:00:54 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14OO1i-000AXX-00; Thu, 01 Feb 2001 18:00:10 +0000 Date: Thu, 1 Feb 2001 18:00:10 +0000 From: Tony Finch To: Kris Kennaway Cc: bsddiy , freebsd-net@FreeBSD.ORG Subject: Re: sendfile() Message-ID: <20010201180010.Q70673@hand.dotat.at> References: <1217774688.20010201133139@163.net> <20010201023825.A71975@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010201023825.A71975@xor.obsecurity.org> Organization: Covalent Technologies, Inc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kris Kennaway wrote: >On Thu, Feb 01, 2001 at 01:31:39PM +0800, bsddiy wrote: > >> I don't want to bring flame war, but the following Linus' words may >> be right: > >Did you have a point to make here? If so, I missed it. I've been discussing this with a few people recently (fortunately I didn't lose the mail from Linus when my laptop was stolen) after I stumbled across the TCP_NOPUSH option, which is superficially similar to TCP_CORK. Linus's argument against the HP/UX and BSD sendfile() is that, for example, in the presence of pipelined HTTP requests it isn't possible to avoid poor packet boundaries between responses. TCP_NOPUSH does help to solve this problem (it was designed to hack around problems with the interaction between mbuf sizes and sosend and tcp_output) but it introduces a new problem: at the end of a chain of HTTP responses you want the last segment to go out quickly rather than waiting for more data to fill the segment. For this reason turning off TCP_CORK pushes out queued data, but this isn't the case for TCP_NOPUSH. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "And remember my friend, future events such as these will affect you in the future." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message