On Monday 27 August 2007 22:37, David Miller wrote: > From: Jan-Bernd Themann <[EMAIL PROTECTED]> > Date: Mon, 27 Aug 2007 11:47:01 +0200 > > > So the question is simply: Do we want drivers that need (benefit > > from) a timer based polling support to implement their own timers > > each, or should there be a generic support? > > I'm trying to figure out how an hrtimer implementation would > even work. > > Would you start the timer from the chip interrupt handler? If so, > that's taking two steps backwards as you've already taken all of the > overhead of running the interrupt handler.
I'm also still trying to understand how hrtimer work exactly. The implementation of hrtimers for P6 has not been finished yet, so I can't do experiments with hrtimers and eHEA now. I will try the following scheme (once we get hrtimers): Each device (queue) has a hrtimer. Schedule the timer in the poll function instead of reactivating IRQs when a high load situation has been detected and all packets have been emptied from the receive queue. The timer function could then just call netif_rx_schedule to register the rx_queue for NAPI again. The advantages of this scheme (if it works as I understood it) would be: - we don't have to modify NAPI - benefit from fairness amoung rx_queues / network devices - The poll function can decide how long to stick to the timer based polling mode, and when to switch back to it's HW IRQs. - driver can determine the time to wait based on the receive queue length and speed Regards, Jan-Bernd - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
