From owner-freebsd-net@FreeBSD.ORG Thu May 31 08:13:00 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 3B99016A46B for ; Thu, 31 May 2007 08:13:00 +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 A073913C48A for ; Thu, 31 May 2007 08:12:59 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 26318 invoked from network); 31 May 2007 07:28:49 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 31 May 2007 07:28:49 -0000 Message-ID: <465E8393.8030201@freebsd.org> Date: Thu, 31 May 2007 10:13:07 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Julian Elischer References: <2a41acea0705301645x65e68e8q23c1b91d5f460ea3@mail.gmail.com> <20070530235456.GA67464@heff.fud.org.nz> <465E140B.2080007@elischer.org> In-Reply-To: <465E140B.2080007@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , Jack Vogel , 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 08:13:00 -0000 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. -- Andre