On Fri, Mar 27, 2009 at 11:05:00AM +0000, Andrew Brampton wrote: > 2009/3/27 Luigi Rizzo <ri...@iet.unipi.it>: > > The load of polling is pretty low (within 1% or so) even with > > polling. The advantage of having interrupts is faster response > > to incoming traffic, not CPU load. > > oh, I was under the impression that polling spun in a tight loop, thus > using 100% of the processor. After a quick test I see this is not the > case. I assume it will get to 100% CPU load if I saturate my network.
Well the motivation for the original polling code in FreeBSD was to keep the CPU usage under strict control -- you could set the max CPU fraction that you wanted to dedicate to packet handling, and you were guaranteed not to exceed that fraction. > > There is nothing difficult in having both active, except figuring > > out a good logic for when to disable polling on an interface > > that has been quiet for a while. > > Looking at Linux's logic, it appears to poll until there are no more > packets, and thus re-enables interrupts. the complete definition should be "no more packets for X seconds". Enabling and disabling interrupts is slightly expensive so you don't want to do it too often. cheers luigi _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
