Bug#277736: NAPI not enabled - should be
On Fri, Oct 22, 2004 at 11:31:33AM -0700, Simon Kirby wrote:
> 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
There is a team looking after the debian kernel,
debian-kernel@lists.debian.org. I am one of the members of that team. I
usually do i386 and 2.4 stuff. But generally help out wherever it is
needed.
> <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...)
My reading of that is that if it is off it hurts some users and
helps others, but if it is on then the roles are just reversed.
Its just a matter of who you want the winners to be.
The current default seems sensible so it is probably best to
leave it as be.
> 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).
Actually, I double-checked and it does not seem to be enabled
for any of the builds in 2.6.8.
--
Horms
Reply to: