lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 10 Sep 2007 10:33:34 +0100
From:	James Chapman <>
To:	Mandeep Singh Baines <>
	Stephen Hemminger <>
Subject: Re: RFC: possible NAPI improvements to reduce interrupt rates for
 low traffic rates

Mandeep Singh Baines wrote:
>> Why would using a timer to hold off the napi_complete() rather than 
>> jiffy count limit the polls per packet to 2?
> I was thinking a timer could be used in the way suggested in Jamal's
> paper. The driver would do nothing (park) until the timer expires. So
> there would be no calls to poll for the duration of the timer. Hence,
> this approach would add extra latency not present in a jiffy polling
> approach.

Ah, ok. I wasn't planning to test timer-driven polling. :)

>> Why wouldn't it be efficient? It would usually be done by reading an 
>> "interrupt pending" register.
> Reading the "interrupt pending" register would require an MMIO read.
> MMIO reads are very expensive. In some systems the latency of an MMIO
> read can be 1000x that of an L1 cache access.

Agreed. Testing for any work being available should be as efficient as 
possible and would be driver specific.

James Chapman
Katalix Systems Ltd
Catalysts for your Embedded Linux software development

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists