Date: Thu, 10 Jan 2008 14:12:53 +1100 From: Lawrence Stewart <lastewart@swin.edu.au> To: Andre Oppermann <andre@freebsd.org> Cc: James Healy <jhealy@swin.edu.au>, arch@freebsd.org, Robert Watson <rwatson@freebsd.org>, net@freebsd.org Subject: Re: Coordinating TCP projects Message-ID: <47858D35.6060006@swin.edu.au> In-Reply-To: <476A45D6.6030305@freebsd.org> References: <20071219123305.Y95322@fledge.watson.org> <47693DBD.6050104@swin.edu.au> <476A45D6.6030305@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47858D35.6060006>