netdev - Re: RFC: possible NAPI improvements to reduce interrupt rates for low traffic rates

lists.openwall.net		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 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:20:15 +0100
From:	James Chapman <jchapman@...alix.com>
To:	hadi@...erus.ca
CC:	netdev@...r.kernel.org, davem@...emloft.net, jeff@...zik.org,
	mandeep.baines@...il.com, ossthema@...ibm.com,
	Stephen Hemminger <shemminger@...l.org>
Subject: Re: RFC: possible NAPI improvements to reduce interrupt rates for
 low traffic rates

jamal wrote:

> If the problem i am trying to solve is "reduce cpu use at lower rate",
> then this is not the right answer because your cpu use has gone up.

The problem I'm trying to solve is "reduce the max interrupt rate from 
NAPI drivers while minimizing latency". In modern systems, the interrupt 
rate can be so high that the CPU spends too much time processing 
interrupts, resulting in the system's behavior seen by the user being 
degraded.

Having the poll() called when idle will always increase CPU usage. But 
the feedback you and others are giving encourages me to find a better 
compromise. At the end of the day, it's going to be a trade-off of cpu 
and latency. The trade-off will be different for each hardware system 
and application environment so parameters need to be tunable.

I'll go away and do some tests. I'll post results here for discussion later.

Thanks for your feedback.

-- 
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html