Date: Thu, 31 May 2007 19:29:06 +0100 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Jack Vogel <jfvogel@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: driver packet coalesce Message-ID: <465F13F2.7070404@FreeBSD.org> In-Reply-To: <2a41acea0705311056y7064ae79y6cd7a6a46d05c13b@mail.gmail.com> References: <2a41acea0705301645x65e68e8q23c1b91d5f460ea3@mail.gmail.com> <20070531133828.GB4675@obelix.dsto.defence.gov.au> <2a41acea0705311056y7064ae79y6cd7a6a46d05c13b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jack Vogel wrote: > On 5/31/07, Wilkinson, Alex <alex.wilkinson@dsto.defence.gov.au> wrote: >> 0n 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? >> >> erm, what is meant by "coalesce" ? >> > combining packets before sending to the stack, aka LRO. Yup - the firmware for the card's LRO engine would have to know not to coalesce packets not destined for the local host. I speculate many cards are not smart enough to do this, and LRO is an all-or-nothing proposition, as it's a technology designed to optimize for hosts, not routers; see recent discussions/slanging matches on end2end. At the moment there is no central place where we track all layer 2 addresses for which traffic should be delivered locally. This would logically belong in struct ifnet, and clients e.g. CARP would have to be taught to add their layer 2 endpoint addresses there. It seems acceptable to disable LRO if bridging is on and document this behaviour. BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?465F13F2.7070404>