From owner-freebsd-net@FreeBSD.ORG Thu Jan 10 04:06:42 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5A8916A418; Thu, 10 Jan 2008 04:06:42 +0000 (UTC) (envelope-from lastewart@swin.edu.au) Received: from swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.222]) by mx1.freebsd.org (Postfix) with ESMTP id 7B64F13C459; Thu, 10 Jan 2008 04:06:42 +0000 (UTC) (envelope-from lastewart@swin.edu.au) Received: from [136.186.229.95] (lstewart.caia.swin.edu.au [136.186.229.95]) by swin.edu.au (8.13.6.20060614/8.13.1) with ESMTP id m0A3Cr1l018960; Thu, 10 Jan 2008 14:12:54 +1100 Message-ID: <47858D35.6060006@swin.edu.au> Date: Thu, 10 Jan 2008 14:12:53 +1100 From: Lawrence Stewart User-Agent: Thunderbird 1.5.0.9 (X11/20070123) MIME-Version: 1.0 To: Andre Oppermann References: <20071219123305.Y95322@fledge.watson.org> <47693DBD.6050104@swin.edu.au> <476A45D6.6030305@freebsd.org> In-Reply-To: <476A45D6.6030305@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.9 X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on gpo2.cc.swin.edu.au Cc: James Healy , arch@freebsd.org, Robert Watson , net@freebsd.org Subject: Re: Coordinating TCP projects X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 04:06:43 -0000 Hi Andre, Andre Oppermann wrote: > Lawrence Stewart wrote: [snip] >> Jim and I recently discussed the idea of implementing autotuning of >> the TCP reassembly queue size based on analysis of some experimental >> work we've been doing. It's a small project, but we feel it would be >> worth implementing. Details follow... >> >> >> Problem description: >> >> Currently, "net.inet.tcp.reass.maxqlen" specifies the maximum number >> of segments that can be held in the reassembly queue for a TCP >> connection. The current default value is 48, which equates to approx. >> 69k of buffer space if MSS = 1448 bytes. This means that if the TCP >> window grows to be more than 48 segments wide, and a packet is lost, >> the receiver will buffer the next 48 segments in the reassembly queue >> and subsequently drop all the remaining segments in the window because >> the reassembly buffer is full i.e. 1 packet loss in the network can >> equate to many packet losses at the receiver because of insufficient >> buffering. This obviously has a negative impact on performance in >> environments where there is non-zero packet loss. >> >> With the addition of automatic socket buffer tuning in FreeBSD 7, the >> ability for the TCP window to grow above 48 segments is going to be >> even more prevalent than it is now, so this issue will continue to >> affect connections to FreeBSD based TCP receivers. >> >> We observed that the socket receive buffer size provides a good >> indication of the expected number of bytes in flight for a connection, >> and can therefore serve as the figure to base the size of the >> reassembly queue on. > > I've got a rewritten and much more efficient tcp_reass() function > in my local tree. I'll import it into Perforce next week with all > the other stuff. You may want to base your auto-sizing work on it. > The only missing parts are some statistics gathering. > Where abouts is this code? A cursory browse through the Perforce web front-end reveals nothing. We're going to start work on the TCP reassembly queue autotuning patch now and if you think we should base it on your new tcp_reass() we need to have a look at it. Cheers, Lawrence