Thread (42 messages) 42 messages, 10 authors, 2007-08-29

Re: RFC: issues concerning the next NAPI interface

From: David Miller <davem@davemloft.net>
Date: 2007-08-28 20:22:53
Also in: lkml

From: Jan-Bernd Themann <redacted>
Date: Tue, 28 Aug 2007 13:19:03 +0200
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.
Interrupt mitigation only works if it helps you avoid interrupts.
This scheme potentially makes more of them happen.

The hrtimer is just another interrupt, a cpu locally triggered one,
but it has much of the same costs nonetheless.

So if you set this timer, it triggers, and no packets arrive, you are
taking more interrupts and doing more work than if you had disabled
NAPI.

In fact, for certain packet rates, your scheme would result in
twice as many interrupts than the current scheme.

This is one of several reasons why hardware is the only truly proper
place for this kind of logic.  Only the hardware can see the packet
arrive, and do the interrupt deferral without any cpu intervention
whatsoever.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help