Polling for ath driver

[Sam Leffler]

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