(Note that I hadn't read the NAPI paper until after I posted the above, and
it appears that I was describing pretty much what NAPI already does ;-). In
light of that, I wholly agree that NAPI is a superior solution for handling
IRQ overload from a network device.
> Anyway it up to driver to decide this policy. If the driver returns
> "not_done" it is simply polled again. So low-rate network drivers can have
> a different policy compared to an OC-48 driver. Even continues polling is
> therefore possible and even showstoppers. :-) There are protection for
> polling livelocks.
One question which I have is why would you ever want to continue polling
if there is no work to be done? Is it a tradeoff between the amount of
time to handle an IRQ vs. the time to do a poll? An assumption that if
there was previous network traffic there is likely to be more the next
time the interface is checked (assuming you have other work to do between
the time you last polled the device and the next poll)?
Is enabling/disabling of the RX interrupts on the network card an issue
in the sense of "you need to wait X us after writing to this register
for it to take effect" or other issue which makes it preferrable to have
some "hysteresis" between changing state from IRQ-driven to polling?
Cheers, Andreas
-- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/