At 01:55 29/05/2003 +0900, Takahiro Igarashi wrote:
>[snip]
>what do you means "on the fly" for?  If it is that kernel
>choices ether interrupt-driven or polling on some time, I
>dont know the OSes which do so.  If it requires reasonably,
>I must implement it.
>
>If it is that simply to switch between them, this code is
>partly implemented.  I'll change switch from all or nothing
>to nic base choice.

One possibility would be to
1- switch from interrupt to polling if load is higher than some threshold T1
load may be "speed" of interrupts (or "acceleration" so as to be somewhat
proactive/predictive?)
2- switch back to interrupt if load is below some threshold T2
(with T2 <=3D T1, possibly different).
This requires keeping traffic infos. more elaborate algos might be better
(but would add complexity?)

See also: 'Can I turn on polling only when overloaded, and use interrupts=20
otherwise ?'
in: "Device Polling support for FreeBSD"
http://info.iet.unipi.it/~luigi/polling/

other pointers that might be interesting:

- "Eliminating Receive Livelock in an Interrupt-driven Kernel":
http://www.research.compaq.com/wrl/techreports/abstracts/95.8.html

- "Ethernet Device Polling for OpenBSD"
http://www.stanford.edu/~tedu/polling.html
excerpt: "The current code to switch modes automatically is rather retarded.
It will turn off polling if it doesn't get enough traffic, but the very=20
next packet will turn it back on"

- "Linux* Base Driver for the Intel=AE PRO/100 Family of Adapters"
http://www.intel.com/support/network/adapter/1000/linux/e100.htm
see: RxCongestionControl and PollingMaxWork entries.


mouss