Date: Mon, 04 Sep 2006 12:07:59 +0200 From: Andre Oppermann <andre@freebsd.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-net <freebsd-net@freebsd.org>, freebsd-current <freebsd-current@freebsd.org>, Jack Vogel <jfvogel@gmail.com> Subject: Re: RFC: TSO patch for current Message-ID: <44FBFAFF.3030702@freebsd.org> In-Reply-To: <20060902065044.V84468@fledge.watson.org> References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <20060902065044.V84468@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44FBFAFF.3030702>