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  linux-cve-announce  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:	Wed, 12 Sep 2007 08:12:22 -0400
From:	jamal <>
To:	Bill Fink <>
Cc:	James Chapman <>,,,,,, Stephen Hemminger <>
Subject: Re: RFC: possible NAPI improvements to reduce interrupt rates for
	low traffic rates

On Wed, 2007-12-09 at 03:04 -0400, Bill Fink wrote:
> On Fri, 07 Sep 2007, jamal wrote:

> > I am going to be the devil's advocate[1]:
> So let me be the angel's advocate.  :-)

I think this would make you God's advocate ;->

> I view his results much more favorably.  

The challenge is, under _low traffic_: bad bad CPU use.
Thats what is at stake, correct?

Lets bury the stats for a sec ...

1) Has that CPU situation improved? No, it has gotten worse.
2) Was there a throughput problem? No. 
Remember, this is _low traffic and the complaint is not NAPI doesnt do
high throughput. I am not willing to spend 34% more cpu to get a few
hundred pps (under low traffic!). 
3)Latency improvement is good. But is 34% cost worthwile for the corner
case of low traffic?

Heres an analogy:
I went to buy bread and complained that 66cents was too much for such
a tiny sliced loaf.
You tell me you have solved my problem: asking me to pay a dollar
because you made the bread slices crispier. I was complaining on the _66
cents price_ not on the crispiness of the slices ;-> Crispier slices are
good - but am i, the person who was complaining about price, willing to
pay 40-50% more? People are bitching about NAPI abusing CPU, is the 
answer to abuse more CPU than NAPI?;->
The answer could be "I am not solving that problem anymore" - at least
thats what James is saying;->

Note: I am not saying theres no problem - just saying the result is not
addressing the problem.

> You can't always improve on all metrics of a workload.  

But you gotta try to be consistent. 
If, for example, one packet size/rate got negative results but the next
got positive results - thats lacking consistency. 

> Sometimes there
> are tradeoffs to be made to be decided by the user based on what's most
> important to that user and his specific workload.  And the suggested
> ethtool option (defaulting to current behavior) would enable the user
> to make that decision.

And the challenge is:
What workload is willing to invest that much cpu for low traffic?
Can you name one? One that may come close is database benchmarks for
latency - but those folks wouldnt touch this with a mile-long pole if
you told them their cpu use is going to get worse than what NAPI (that
big bad CPU hog under low traffic) is giving them.

> P.S.  I agree that some tests run in parallel with some CPU hogs also
>       running might be beneficial and enlightening.



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