From owner-freebsd-current@FreeBSD.ORG Sat Sep 23 10:20:04 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A33716A416 for ; Sat, 23 Sep 2006 10:20:04 +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 5A97043D78 for ; Sat, 23 Sep 2006 10:20:02 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 62209 invoked from network); 23 Sep 2006 10:22:25 -0000 Received: from opi.flirtbox.ch (HELO [127.0.0.1]) ([62.48.0.50]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 Sep 2006 10:22:25 -0000 Message-ID: <45150A51.8080501@freebsd.org> Date: Sat, 23 Sep 2006 12:20:01 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: David Malone References: <4511B9B1.2000903@freebsd.org> <17683.63162.919620.114649@grasshopper.cs.duke.edu> <45145F1D.8020005@freebsd.org> <20060922234708.V11343@fledge.watson.org> <20060923073833.GA10269@walton.maths.tcd.ie> In-Reply-To: <20060923073833.GA10269@walton.maths.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Gallatin , alc@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-current@FreeBSD.org, Robert Watson , tegge@FreeBSD.org Subject: Re: Much improved sendfile(2) kernel implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2006 10:20:04 -0000 David Malone wrote: > On Fri, Sep 22, 2006 at 11:48:23PM +0100, Robert Watson wrote: >> The impact of TSO is clearly dramatic, especially when combined with the >> patch, but I'm a bit concerned by the drop in performance in the patched >> non-TSO case. For network cards which will always have TSO enabled, this >> isn't an issue, but do we see a similar affect for drivers without TSO? >> What can we put this drop down to? > > We probably also need to make sure that any performance increase > in TSO isn't due to us getting TCP congestion control wrong. I think > in Linux they had problems when they first introduced TSO because > TCP was advancing the congestion window by a TSO-sized chunk instead > of a wire packet. OTOH, I think Andre and Drew's tests are low-latency, > so congestion control isn't likely to be playing a big role, so the > improvements are unlikely to be due to this. The congestion window is increased based on the ACK's received. TSO is only done on the send side and only up to the current congestion window. I have been careful not to get any changes in congestion control behavior with TSO. (Which does not mean that there may be other bugs lurking in our congestion control.) -- Andre