From owner-freebsd-current@FreeBSD.ORG Sun Sep 3 00:37:32 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 AB1D016A4E2 for ; Sun, 3 Sep 2006 00:37:32 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9F4E43D6E for ; Sun, 3 Sep 2006 00:37:24 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so1959042pye for ; Sat, 02 Sep 2006 17:37:24 -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=h1LMo8NQBfV2QhXdTxU1WNzKdF7AMPvb3YY6G1vxp7QY/SImZKeo6CuytQE2sSPtN9qMEUPfjH+ttPXGoLXt2ValRDrSI9W+Ps0v15Tdo5nKNv7WNYdGAkZxgXvOvT5/mhCnVSOpS7ym2Rm7sGCW0leOPRRr9Sm6JyH6O+TH6dA= Received: by 10.35.45.1 with SMTP id x1mr6472137pyj; Sat, 02 Sep 2006 17:37:24 -0700 (PDT) Received: by 10.35.119.1 with HTTP; Sat, 2 Sep 2006 17:37:24 -0700 (PDT) Message-ID: <2a41acea0609021737q72d1af79kbc9ef45ac0102f7e@mail.gmail.com> Date: Sat, 2 Sep 2006 17:37:24 -0700 From: "Jack Vogel" To: "Andre Oppermann" In-Reply-To: <44F9384C.9070902@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> <44F9384C.9070902@freebsd.org> Cc: freebsd-net , freebsd-current 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: Sun, 03 Sep 2006 00:37:32 -0000 On 9/2/06, Andre Oppermann wrote: > 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. > > I can't comment on the em part but the tcp_output.c stuff looks > very much like a straight port from NetBSD. If we take code from > the other BSDs we have to remark this in the emails we send with > patches and the commit message (otherwise we get accused of 'stealing > without attribution'). Although the code would work I have some ideas > to implement this in a different way for our stack (we have certain > divergence from the other BSDs). If you don't get an alternative > patch form me until this Thursday be free to go with this patch taking > into consideration Robert's comments and mine from your earlier version. Yes, I was planning on adding the code Robert talked about, it doesnt change anything fundamental in this patch. What I would like to see in some ways is an idea from what Linux does, but it would change the stack more than this does. We would remove all code that segments from tcp and do it just before calling the driver, in effect the routine Robert is talking about would be the normal path, doing software segmentation, and at that same point we would discover that the interface was TSO capable and call that. I think at that point we would have easy access to the ifp struct and it would eliminate the need for the discovery routine in tcp_subr.c. What were you thinking of doing? Cheers, Jack