From owner-freebsd-arch@FreeBSD.ORG Thu Jan 10 09:12:55 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A8AF16A421 for ; Thu, 10 Jan 2008 09:12:55 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4E16613C43E for ; Thu, 10 Jan 2008 09:12:53 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 11939 invoked from network); 10 Jan 2008 08:36:46 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 10 Jan 2008 08:36:46 -0000 Message-ID: <4785E19A.2040102@freebsd.org> Date: Thu, 10 Jan 2008 10:12:58 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Lawrence Stewart References: <20071219123305.Y95322@fledge.watson.org> <47693DBD.6050104@swin.edu.au> <476A45D6.6030305@freebsd.org> <47858D35.6060006@swin.edu.au> In-Reply-To: <47858D35.6060006@swin.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: James Healy , arch@freebsd.org, Robert Watson , net@freebsd.org Subject: Re: Coordinating TCP projects X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 09:12:55 -0000 Lawrence Stewart wrote: > 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. I'll put everything into Perforce this evening (European time). Christmas/newyear didn't provide as much spare time as I had hoped. ;-) -- Andre