Date: Tue, 07 Feb 2006 18:49:00 -0800 From: Sam Leffler <sam@errno.com> To: Michael DeMan <michael@staff.openaccess.org> Cc: "freebsd-net@FreeBSD.org" <freebsd-net@freebsd.org>, nielsen@memberwebs.com Subject: Re: Polling for ath driver Message-ID: <43E95C1C.2030509@errno.com> In-Reply-To: <8D39FF7E-646E-4770-9ABF-337F69344EA7@staff.openaccess.org> References: <20060205011931.E5F08DCA99E@mail.npubs.com> <43E63FC3.2030409@errno.com> <20060206050301.AC895DCAA3F@mail.npubs.com> <8D39FF7E-646E-4770-9ABF-337F69344EA7@staff.openaccess.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Michael DeMan wrote: > Hi, > > Just my 2-cents, but we've found polling to be extremely valuable on > low-end hardware as described here. > > We use it only on fxp drivers, but it moved throughput on 133Mhz > hardware from something around 8Mbps to 20Mbps on regular layer-3 packet > forwarding and also bumped VPN performance up significantly when used > with hardware VPN accelerators. > > Also, since you can force the system to reserve a certain percent for > non-polling tasks, you still have SSH access even when it is running > hard, although I suppose at the risk of perhaps packet loss if your > userland applications use a lot of CPU. > > I have no idea on FBSD 5.4 or 6.0 though and would be curious. We're > running 5.4 on our normal servers now, but I've been nervous moving the > low end equipment off of 4.x because of performance issues. I'm not arguing against polling. I started by saying that adding polling to ath wasn't worthwhile w/o restructuring the driver. I then asked Nate to split out various effects so the polling changes could be evaluated independent of other changes (e.g. polling in the hifn driver). I've done NAPI code for the linux version of the ath driver for embedded applications. If I were building ap's on underpowered platforms like the soekris I'd probably do similar changes. But using polling would depend on the application because it introduces latency and some applications cannot tolerate that latency. I know this from direct experience--try implementing HCF for example. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43E95C1C.2030509>