Bug#277736: NAPI not enabled - should be
On Fri, Oct 22, 2004 at 05:20:12PM +0900, Horms wrote:
> Hi Simon,
>
> I am a little wary of enabling an option that will effect the behaviour
> of device drivers. I observe that for the ES 3.0 WS kernel it only seems
> to be enabled for E1000. I also observe that it is enabled for smp
> builds of 2.6.8 in Debian, except for on the E100. Which makes me
> suspect it may be problematic or at least not trusted on some cards.
It doesn't make any sense at all to have it on with SMP and off with UP,
as if any issues occur it would be more likely with SMP. Well, I asked
around and some discussion ensued:
<Simon> the deb kernel maintainer is asking if there might be any
negative effects of enabling NAPI in 2.6, noting that RH ES only
enables it for e1000..
<Simon> I suppose it might increase the kernel size slightly :)
<arjan> who is the debian kernel maintainer these days ?
<mpm> There's like one per arch..
* arjan ponders doing a deb kernel ;)
<Simon> Simon Horman <horms@debian.org> for i386, apparently
<Simon> well, he replied to the bug anyway :)
<willy> horms does 2.4
<mpm> There are situations where NAPI is slower and others where it's
faster, it's not very clear-cut as far as I can see.
<mbligh> mpm, it seems to work better AFAICS when the machine is flat out
<mbligh> if it's only half-bandwidth of the attatched network, it sucks
<Simon> napi doesn't kick in until it's saturated normally, though,
right? so it shouldn't mess with anything until it would otherwise be
choked anyway
<Simon> except for bursty bits, maybe
<mpm> NFS over gigabit is all about bursty.
<Simon> it's interesting that it isn't an option for tg3 but is for e1000
<Simon> yeah.. I found that tweaking the e100 defaults to not coalesce as
much helped a lot for nfs traffic here, but that had nothing to do
with napi...
<arjan> Simon: for tg3 it's required to work around hw bugs iirc
<mpm> That's about 80% of the driver.
<arjan> true
<arjan> amazing but true
<Simon> is there much overhead in the interrupt mask/unmask or anything?
I don't see why it would end up slowing anything down
<freitag> simon: NAPI makes a lot of benchmarks slower
<mpm> Simon: Because you're polling for packets, latency can be increased
when load is low..
<Simon> mpm: but it uses interrupts when load is low..
<arjan> threshold probably needs tweaking ;)
<mpm> Simon: There's always a hysteresis issue, regardless of where you
set the threshold.
<Simon> right, ok. hmm.
<Simon> well, it's an option of whether that option makes it in to sarge
or not unless security issues arise later.. too bad it's not
configurable from userspace..
<Simon> although I guess it is if you mess enough with the thresholds
<mpm> Runtime configurable is a reasonable thing to have, sounds like the
sort of thing Hemminger kicks out in his sleep..
<willy> sounds like the kind of thing Linus hates
<willy> obviously the driver should be switching in and out of NAPI mode
*by itself*
<freitag> simon: it would be pretty easy to do (it's on my todo list
somewhere)
<mpm> willy: It's no different than westwood vs vegas type stuff. The
jury's out on the optimal solution..
<willy> mpm: it's no different from having knobs to twiddle on the VM ...
<mpm> Except that it all funnels through davem and Linus rarely meddles
there..
<mpm> Note that we have VM and scheduler knobs these days.
<Simon> yeah...there definitely are lots of knobs lately :) but it would
be nice if it could just be fixed so that it always is the best case..
<willy> mpm: yes, knobs creep back in, but round about 2.2, Linus just
deleted them all
<freitag> simon: together with world peace yes
<Simon> world peace and napi.. sounds good
<mpm> I think having a knob for server vs laptop is unavoidable. And
general latency vs throughput knobs might be unavoidable in the
network in places.
(The conversation degenerates...)
Well, if Debian already has it enabled for SMP kernels I really doubt it
will be a problem for UP kernels. My perspective is that I basically
can't use the stock kernels on a lot of our boxes because NAPI is
disabled and that means the boxes will choke with 1/5th of the network
load (mostly only DoS-type network load, though).
Simon-
Reply to: