Date: Mon, 21 May 2007 14:48:33 -0400 From: Andrew Gallatin <gallatin@cs.duke.edu> To: Andrew Gallatin <gallatin@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/mxge eth_z8e.dat.gz.uu ethp_z8e.dat.gz.uu if_mxge.c if_mxge_var.h mxge_lro.c mxge_mcp.h Message-ID: <20070521144833.A15093@grasshopper.cs.duke.edu> In-Reply-To: <200705211832.l4LIWSo9009052@repoman.freebsd.org>; from gallatin@FreeBSD.org on Mon, May 21, 2007 at 06:32:04PM %2B0000 References: <200705211832.l4LIWSo9009052@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Gallatin [gallatin@FreeBSD.org] wrote: > > - Switch the driver from chaining MJUMPAGESIZE clusters to using > MJUM9BYTES clusters to avoid mbuf chaining overheads. Due to this > change, people running obsolete f/w images will be limited to an MTU of > PAGE_SIZE - 16. This takes mxge jumbo frame receive performance from 9.3Gb/s to line rate on high-end machines (dual dual-core woodcrests), and from ~6.9Gb/s to ~8.2Gb/s on low end machines (2.0GHz athlon64 x2). > - Add (disabled by default) support for Large Receive Offload. For the curious, LRO is analagous to a receive side version of TSO. The NIC (or driver) merges several consecutive segments from the same connection, fixing up checksums, etc. Rather than up to 45 separate 1500 byte frames (meaning up to 45 trips through the network stack), the driver merges them into one 65212 byte frame. When enabled (and the overlength frame check in ether_input defeated) LRO roughly doubles standard frame performance on anything I've tried. Drew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070521144833.A15093>