Date: Thu, 31 May 2007 10:54:17 -0700 From: "Jack Vogel" <jfvogel@gmail.com> To: "Andre Oppermann" <andre@freebsd.org> Cc: freebsd-net <freebsd-net@freebsd.org>, Julian Elischer <julian@elischer.org>, Andrew Thompson <thompsa@freebsd.org> Subject: Re: driver packet coalesce Message-ID: <2a41acea0705311054g19598073u3fc406c9a477f12c@mail.gmail.com> In-Reply-To: <465E8393.8030201@freebsd.org> References: <2a41acea0705301645x65e68e8q23c1b91d5f460ea3@mail.gmail.com> <20070530235456.GA67464@heff.fud.org.nz> <465E140B.2080007@elischer.org> <465E8393.8030201@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/31/07, Andre Oppermann <andre@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2a41acea0705311054g19598073u3fc406c9a477f12c>