From owner-freebsd-current@FreeBSD.ORG Mon Sep 4 10:08:02 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 5B9A516A4E2 for ; Mon, 4 Sep 2006 10:08:02 +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 11AC443D4C for ; Mon, 4 Sep 2006 10:08:00 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 18418 invoked from network); 4 Sep 2006 09:53:25 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 4 Sep 2006 09:53:25 -0000 Message-ID: <44FBFAFF.3030702@freebsd.org> Date: Mon, 04 Sep 2006 12:07:59 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Robert Watson References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <20060902065044.V84468@fledge.watson.org> In-Reply-To: <20060902065044.V84468@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , freebsd-current , Jack Vogel Subject: Re: RFC: TSO patch for current 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: Mon, 04 Sep 2006 10:08:02 -0000 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