From owner-freebsd-arch@FreeBSD.ORG  Thu May 29 09:20:52 2003
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 5C5B837B401
	for <arch@freebsd.org>; Thu, 29 May 2003 09:20:52 -0700 (PDT)
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by mx1.FreeBSD.org (Postfix) with ESMTP id D10BC43F85
	for <arch@freebsd.org>; Thu, 29 May 2003 09:20:51 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: from apollo.backplane.com (localhost [127.0.0.1])
	by apollo.backplane.com (8.12.9/8.12.6) with ESMTP id h4TGKpVI078313;
	Thu, 29 May 2003 09:20:51 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.12.9/8.12.6/Submit) id h4TGKobi078312;
	Thu, 29 May 2003 09:20:50 -0700 (PDT)
Date: Thu, 29 May 2003 09:20:50 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200305291620.h4TGKobi078312@apollo.backplane.com>
To: Terry Lambert <tlambert2@mindspring.com>
References: <200305281755.h4SHtbu05504@windsor.research.att.com>
	<3ED5961E.5DE0F41B@mindspring.com>
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
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 29 May 2003 16:20:52 -0000

:Bill Fenner wrote:
:> Why not set PRUS_MORETOCOME on all but the final pru_send() call?
:
:If the file is larger than `sysctl net.inet.tcp.sendspace`, then
:this code in do_sendfile():
:
:                if (sbspace(&so->so_snd) < so->so_snd.sb_lowat) {
:                        if (so->so_state & SS_NBIO) {
:                                m_freem(m);
:                                sbunlock(&so->so_snd);
:                                splx(s);
:                                error = EAGAIN;
:                                goto done;
:                        }
:                        error = sbwait(&so->so_snd);
:
:will result in you sleeping with PRUS_MORETOCOME set, but with
:no more being sent because the send buffer doesn't get emptied,
:as it's waiting for more data to send.
:
:-- Terry

     Not unless the send buffer is substantially near the size of a single
     packet, which it isn't (it's far larger).  PRUS_MORETOCOME is smarter
     then that, Terry.  tcp_output() just uses it as a hint, it doesn't 
     unconditionally hold off a flush.

     The code to refer to is netinet/tcp_output.c around line 313 (in stable),
     in tcp_output().  The section within the if (len) { ... } sequence.
     This section does all tests related to sending a packet and as you can
     see TF_MORETOCOME will not prevent the data from being flushed the
     more there is enough to fill a packet.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>