Date: Mon, 4 Sep 2006 23:21:02 -0700 From: "Jack Vogel" <jfvogel@gmail.com> To: "Andre Oppermann" <andre@freebsd.org> Cc: freebsd-net <freebsd-net@freebsd.org>, freebsd-current <freebsd-current@freebsd.org>, Robert Watson <rwatson@freebsd.org> Subject: Re: RFC: TSO patch for current Message-ID: <2a41acea0609042321h97feecal9b50979aa964c257@mail.gmail.com> In-Reply-To: <44FBFAFF.3030702@freebsd.org> References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <20060902065044.V84468@fledge.watson.org> <44FBFAFF.3030702@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/4/06, Andre Oppermann <andre@freebsd.org> wrote: > Robert Watson wrote: > > 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. > > In the patch I posted yesterday into this thread the TSO decision is > done at connection setup time in tcp_mss() where all other initial TCP > connection parameters are initilized as well. If the same interface > we took the MTU values from, is found to support TSO it gets enabled for > this connection too. Should the egress interface change during the > lifetime of the connection and the new one doesn't support TSO we get > an EMSGSIZE error from ip_output(), disable TSO for this connection and > have tcp_output() resend the data again while doing the segmentation > itself as usual. Should the connection change back to the TSO capable > interface later on we don't re-enable TSO for the connection though. > OTOH having a bulk transfer TCP session (where TSO actually helps) migrate > between interface is a *very* rare occurence and not worth special casing > for it. This looks cool Andre, I've been in vacation mode the past couple days, but when I get to work tomorrow I'll look at it more closely and give it a try with my driver changes. Thanks :) Jack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2a41acea0609042321h97feecal9b50979aa964c257>