From owner-freebsd-net@FreeBSD.ORG Thu May 31 17:54:18 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98F8316A473 for ; Thu, 31 May 2007 17:54:18 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 7211713C480 for ; Thu, 31 May 2007 17:54:18 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id m33so330437wag for ; Thu, 31 May 2007 10:54:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ldHRoH7QohV2Eet9ceAy4/w0KZWEXOvmHNsODY7kB2QnIO2y9RqNJd/go+42PQd3GH6kDQmAJE7/HWAocIkzgsfcm3vT5qSPf4PLQ4gBTRGoMm9g0spE7tVwkkvxMTOj4Ku5A3eNOBzCeDDBoE3ojKyB3omZXvQcuiyXxERl20g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ew/iIfN2veEJZcptze+5kHvTGZ6R9MfzHIDKSAjPhsTDUXlbufBQpZP6lftPZisWm5WGJARQ9N7aZYeNedpgpxZdO15S+qfvmRbZVHpHdoaBVFolF/lyctLTDkCDAq00kFnb0AYDTnmAHMo6MWpcUYWOvzsPeRB1ouT89O7PHts= Received: by 10.115.15.1 with SMTP id s1mr923266wai.1180634057992; Thu, 31 May 2007 10:54:17 -0700 (PDT) Received: by 10.114.126.10 with HTTP; Thu, 31 May 2007 10:54:17 -0700 (PDT) Message-ID: <2a41acea0705311054g19598073u3fc406c9a477f12c@mail.gmail.com> Date: Thu, 31 May 2007 10:54:17 -0700 From: "Jack Vogel" To: "Andre Oppermann" In-Reply-To: <465E8393.8030201@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0705301645x65e68e8q23c1b91d5f460ea3@mail.gmail.com> <20070530235456.GA67464@heff.fud.org.nz> <465E140B.2080007@elischer.org> <465E8393.8030201@freebsd.org> Cc: freebsd-net , Julian Elischer , Andrew Thompson Subject: Re: driver packet coalesce X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2007 17:54:18 -0000 On 5/31/07, Andre Oppermann wrote: > Julian Elischer wrote: > > Andrew Thompson wrote: > >> On Wed, May 30, 2007 at 04:45:05PM -0700, Jack Vogel wrote: > >>> Does any driver do this now? And if a driver were to coalesce > >>> packets and send something up the stack that violates mss > >>> will it barf? > >> > >> It would barf for things like bridging where the packet gets spit out a > >> different interface. The bridge driver already has code to disable > >> txcsum so it could be made to handle that too. > >> > >> > >> Andrew > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > This is part od TOE right? > > No, LRO (Large Receive Offload). > > > I presume that it wouldn't coalesce packets that are not destined for > > the local > > machine? would it coalesce in promiscuous mode? I guess it would only > > be able to coalesce TCP packets that are adjacent in the same session. > > Whether it also can coalesce adjacent packets that are destined for another > > machine (for which it is not running the session) is not known... I > > would guess it > > wouldn't do it. > > These are all nasty problems that should be handled in one central > place for various protocols (primarily TCP right now). For TCP there > are a number of obvious and non-obvious interaction issues with LRO > to be handled. For example LRO may have a drastic effect on stacks > that don't (yet) make use of ABC and increase the CWND by one for > every ACK received. With LRO up to some 44 segments may be aggregated. > On back to back connections with microsecond RTT this isn't much a > problem. However once you have even 1ms performance goes way down. > The LRO implementation (in the driver) has to be aware of all these > issues and how the TCP stack treats them. That's why I want to have > only one LRO implementation in the base system that is used by all > drivers. >From email I've seen it appears Linux is working thru this issue as well, and I agree that it makes sense to have one implementation, so lets get going on it :) Jack