Date: Fri, 18 Oct 2002 15:53:34 -0400 From: Don Bowman <don@sandvine.com> To: 'Luigi Rizzo' <rizzo@icir.org>, Kelly Yancey <kbyanc@posi.net> Cc: Petri Helenius <pete@he.iki.fi>, Lars Eggert <larse@ISI.EDU>, freebsd-net@FreeBSD.ORG Subject: RE: ENOBUFS Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022CCA@mail.sandvine.com>
next in thread | raw e-mail | index | archive | help
> From: Luigi Rizzo [mailto:rizzo@icir.org] > On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote: > ... > > Hmm. Might that explain the abysmal performance of the > em driver with > > packets smaller than 333 bytes? > > what do you mean ? it works great for me. even on -current i > can push out over 400kpps (64byte frames) on a 2.4GHz box. 400kpps seems like very poor performance. Unless I do the math wrong, this is only ~200Mbps, the nic should be able to allow ~2-3Mpps (GE bidirectional). The performance tests I've been doing have also shown that the broadcom chip (with the bge driver) outperforms the intel chip (with the em driver) for small packets. This could be due to tuning in the driver (there are different tunables in both cases) or due to erroneous/over-aggressive workarounds. For example, in the broadcom GE chip, the driver blindly turns off hardware acceleration for checksums, when it really only needs to do this for certain early rev silicon. This had a negligible performance improvement @ any rate owing to the high speed of the processor :) The linux driver (avail from broadcom) provides some hints here. The most pressing limit I ran into was the user->kernel up/down stack interface. Using 'iperf' with UDP, the transmitter runs out of gas just going up and down the stack, in and out of kernel, over the sysctl, etc long before the nic runs out of speed (for small packets). Seems like there's some interest in a bakeoff :) I'm willing to post some results when I have them avail. My $0.02 is that there is likely some outdated 'war stories' on all silicon that tends to end up implemented as work-arounds in the driver long after they are fixed in silicon. The (insert negative opinion) strategy of the silicon vendors of hiding their errata and datasheets makes for much poorer utilisation of their product. At least intel has had the good sense to release their driver. --don To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE045D4D9F7AED4CBFF1B3B813C8533701022CCA>