From owner-freebsd-arch@FreeBSD.ORG Tue May 27 09:30:37 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8586237B401 for ; Tue, 27 May 2003 09:30:37 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBA9543F85 for ; Tue, 27 May 2003 09:30:36 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfjqj.dialup.mindspring.com ([165.247.207.83] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19KhLM-0000SY-00; Tue, 27 May 2003 09:30:33 -0700 Message-ID: <3ED39260.27639328@mindspring.com> Date: Tue, 27 May 2003 09:29:20 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Sysoev References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4964b9ff6710088d37d588dac50df4af3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: arch@freebsd.org Subject: Re: sendfile(2) SF_NOPUSH flag proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2003 16:30:37 -0000 Igor Sysoev wrote: > > Actually, the functionality can be implemented *without* going > > and implementing the API. It should really be contrlled already > > by the TCP_NODELAY option *not* having been set by the user, and, > > for last-block next-first-block coelescing, by TCP_NOPUSH *having* > > been set. > > It's not an implementing the API. It's an addition to the already existed > API - sendfile(2). sendfile(2) already has the flags parameter and this > parameter is currently unused and should be zero. I propose two sendfile(2) > flags - SF_NOPUSH and SF_PUSH. Why? Why not just fix the broken sendfile(2) implementation, instead? > > > 2) The new feature provides significant performance benefit. In this > > > case, I believe the overhead of calling setsockopt(2) is negligible > > > so the performance gain would be negligible. > > > > The overhead of toggling it would be costly. However, I really > > don't understand why he isn't just not setting TCP_NODELAY in > > the first place, since it's an affirmative option, and then > > leaaving the socket alone to act like it's supposed to act. > > TCP_NODELAY is not set. So there's no barrier to you fixing this by either breaking up tcp_output() into two functions, or lazy-calling tcp_output(), instead of aggreesively calling it between headers and file data and file data and trailers in sendfile(2). Right? No API change necessary? -- Terry