From owner-freebsd-net@FreeBSD.ORG Sat Sep 2 05:53:56 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20D5B16A4DA; Sat, 2 Sep 2006 05:53:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9AF543D46; Sat, 2 Sep 2006 05:53:55 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 61D8746C9F; Sat, 2 Sep 2006 01:53:55 -0400 (EDT) Date: Sat, 2 Sep 2006 06:53:55 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jack Vogel In-Reply-To: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> Message-ID: <20060902065044.V84468@fledge.watson.org> References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net , freebsd-current Subject: Re: RFC: TSO patch for current 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: Sat, 02 Sep 2006 05:53:56 -0000 On Fri, 1 Sep 2006, Jack Vogel wrote: > This is a patch for the stack and the em driver to enable TSO on CURRENT. > Previously I had problems getting it to work, but this is functional. > > I should note that CURRENT is being a pain right now, when I comment out em > in the config the kernel panics coming up, so I had to substitute this code > into the tree. Rather bizarre :) > > I have this functionality running on a 6.1 based system, and our test group > is already testing against that driver, so far things are looking good. > > I have designed it so the driver can continue to be built without support. > There is also a sysctl in the stack code so you can set > net.inet.tcp.tso_enable on or off and compare. > > I know there may be some refinements to add in, but I would like to get this > into CURRENT as a start. Per my earlier comments, I would like to see the issue of doing an on-demand segmentation of TCP at the IP layer in the event that the early route decision becomes stale (i.e., ipfw fwd, ipsec, etc), as occurs in the NetBSD code. Likewise, I think Andre's comment about making the routing decision up front for the TCP connection as part of the existing search for PMTU information makes sense. I'm more interested in seeing the former addressed than the latter before the commit, though, which can quite easily follow. Robert N M Watson Computer Laboratory University of Cambridge