From owner-freebsd-current@FreeBSD.ORG Tue Sep 5 06:21:06 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 8E82E16A4E0 for ; Tue, 5 Sep 2006 06:21:06 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31EB343D5C for ; Tue, 5 Sep 2006 06:21:03 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so3275045pye for ; Mon, 04 Sep 2006 23:21:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JIPyAKjbgRNge/7HSUnPjr8vSvJZOrj0DeaDcOhFyrjDQu+NgHPLmXFRsJEbm4arh2SFy81CEM28UF14/vowultovbv0F52n6tGr9K+TwFYDyF/JgJSclGZ8PhPy0blA1r7HZLVcTzYCY+D5b/VT1NvHiF1u4tUEFqgJ4Ckuuuw= Received: by 10.35.60.15 with SMTP id n15mr11777642pyk; Mon, 04 Sep 2006 23:21:02 -0700 (PDT) Received: by 10.35.119.1 with HTTP; Mon, 4 Sep 2006 23:21:02 -0700 (PDT) Message-ID: <2a41acea0609042321h97feecal9b50979aa964c257@mail.gmail.com> Date: Mon, 4 Sep 2006 23:21:02 -0700 From: "Jack Vogel" To: "Andre Oppermann" In-Reply-To: <44FBFAFF.3030702@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <20060902065044.V84468@fledge.watson.org> <44FBFAFF.3030702@freebsd.org> Cc: freebsd-net , freebsd-current , Robert Watson 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: Tue, 05 Sep 2006 06:21:06 -0000 On 9/4/06, Andre Oppermann 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