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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
