av> Without polling it transfers like 8MB/s, with polling it does av> less than this and there is twice the latency.

that's not what i expected on both counts.

but the supposed benefit of polling is increase in pps capacity, not reduced latency.

In theory, it is supposed to operate normally with interrupts enabled for small-packets-per-second loads, giving the same latency as without polling. For your ping test where the bridge is presumably idle except for the ping, I'd expect that---interrupt mode, and the same latency as without polling.

Somewhere around 1 - 10kpps it should switch to polling and collect batches of 1ms of packets on each timer interrupt, giving you <= 1ms additional latency (HZ=1000) compared to without polling. In exchange for the added latency, the CPU load should be lower, and the max pps it can handle before dropping packets should be greater. Again the tradeoff should only happen under load, not just an idle line except ping.

polling is mostly about high pps, so that would be either gigabit without jumboframes, or 100Mbit/s with small packets (VoIP or DDoS). so for 100Mbit/s and big packets like FTP I'm not surprised that you see no benefit, but I would still have expected the transfer speed with polling to be either unaffected or better.

...guess it's not what I expected. :)