Date: Sat, 2 Sep 2006 06:53:55 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Jack Vogel <jfvogel@gmail.com> Cc: freebsd-net <freebsd-net@freebsd.org>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: RFC: TSO patch for current Message-ID: <20060902065044.V84468@fledge.watson.org> In-Reply-To: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060902065044.V84468>