Device polling performance

[TM4525 at aol.com]

In a message dated 9/25/04 1:06:40 PM Eastern Daylight Time, cswiger at mac.com 
writes:
> It seems beyond unreasonable that, with interrupts enabled, 55% of the 
system 
> is used, and with polling, ~ zero.

"Inconceivable!"
"Erm...I do not think that word means what you think it means."

It's probably easier to claim device polling works by black magic, then to 
explain just how much useless overhead is added when the CPU has to service 
tens of thousands of interrupts per second at very high packet rates.  If you 
only need to bridge packets from one NIC to another, modern NICs will do 
almost all of the work (busmastering DMA, checksum offloading, etc) without 
needing any CPU time at all.

If you've got good hardware, device polling means that the system is usually 
constrained by PCI bus throughput and the actual network transmission speed 
of 
the NICs themselves, not by CPU overhead.

If you attempt to use crappy hardware (try digging up some 10Mbs ISA NICs), 
then the CPU will have to do a lot more work, and device polling will take up 
more than nearly zero CPU time.  If you do routing, have firewall rules 
(particularly using dynamic stateful rules), or NAT (particularly running 
userland natd), you'll probably see significant CPU being used there.
The EVIDENCE is to the contrary, since it seems that a 2.4Ghz system will be 
saturated when bridging ~250Kpps with device-polling enabled, based on polling 
stats and userland benchmarking, even though the system claims to be 100% 
idle. Interestingly, its about the same with interrupt enabled.

The POINT is that since there is no way to measure the performance, you've 
got a bunch of guys who think they've figured something out touting 
device-polling without having a clue what the performance advantages (or consequences) 
are, so it might as well be black magic, or snake oil, since you are as blind as 
a bat in your assessments.

cheers,

TM