From owner-cvs-sys  Mon Jul  6 13:01:35 1998
Return-Path: <owner-cvs-sys>
Received: (from daemon@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id NAA08545
          for cvs-sys-outgoing; Mon, 6 Jul 1998 13:01:35 -0700 (PDT)
          (envelope-from owner-cvs-sys)
Received: from tarsier.ca.sandia.gov (tarsier.ca.sandia.gov [146.246.246.124])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA08496;
          Mon, 6 Jul 1998 13:01:19 -0700 (PDT)
          (envelope-from cc@tarsier.ca.sandia.gov)
Received: from tarsier.ca.sandia.gov (localhost [127.0.0.1])
	by tarsier.ca.sandia.gov (8.8.8/8.8.8) with ESMTP id NAA28886;
	Mon, 6 Jul 1998 13:03:20 -0700 (PDT)
	(envelope-from cc@tarsier.ca.sandia.gov)
Message-Id: <199807062003.NAA28886@tarsier.ca.sandia.gov>
X-Mailer: exmh version 2.0.2 2/24/98
To: Bill Fenner <fenner@FreeBSD.ORG>
cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-sys@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/kern uipc_socket.c 
In-reply-to: Your message of "Mon, 06 Jul 1998 12:27:17 PDT."
             <199807061927.MAA23940@freefall.freebsd.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 06 Jul 1998 13:03:20 -0700
From: "Chris Csanady" <cc@tarsier.ca.sandia.gov>
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Cool!  I'm quite happy to see a fix for this--could someone please commit
this to -stable?

Chris

>fenner      1998/07/06 12:27:16 PDT
>
>  Modified files:
>    sys/kern             uipc_socket.c 
>  Log:
>  Introduce (fairly hacky) workaround for odd TCP behavior with application
>   writes of size (100,208]+N*MCLBYTES.
>  
>  The bug:
>   sosend() hands each mbuf off to the protocol output routine as soon as it
>   has copied it, in the hopes of increasing parallelism (see
>    http://www.kohala.com/~rstevens/vanj.88jul20.txt ). This works well for
>   TCP as long as the first mbuf handed off is at least the MSS.  However,
>   when doing small writes (between MHLEN and MINCLSIZE), the transaction is
>   split into 2 small MBUF's and each is individually handed off to TCP.
>   TCP assumes that the first small mbuf is the whole transaction, so sends
>   a small packet.  When the second small mbuf arrives, Nagle prevents TCP
>   from sending it so it must wait for a (potentially delayed) ACK.  This
>   sends throughput down the toilet.
>  
>  The workaround:
>   Set the "atomic" flag when we're doing small writes.  The "atomic" flag
>   has two meanings:
>   1. Copy all of the data into a chain of mbufs before handing off to the
>      protocol.
>   2. Leave room for a datagram header in said mbuf chain.
>   TCP wants the first but doesn't want the second.  However, the second
>   simply results in some memory wastage (but is why the workaround is a
>   hack and not a fix).
>  
>  The real fix:
>   The real fix for this problem is to introduce something like a "requested
>   transfer size" variable in the socket->protocol interface.  sosend()
>   would then accumulate an mbuf chain until it exceeded the "requested
>   transfer size".  TCP could set it to the TCP MSS (note that the
>   current interface causes strange TCP behaviors when the MSS > MCLBYTES;
>   nobody notices because MCLBYTES > ethernet's MTU).
>  
>  Revision  Changes    Path
>  1.41      +2 -1      src/sys/kern/uipc_socket.c