netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robert Olsson <Robert.Olsson@data.slu.se>
To: Christopher Chan <cchan@outblaze.com>
Cc: netdev@oss.sgi.com, Robert.Olsson@data.slu.se
Subject: 2.6.4 e100 NAPI - dst cache overflow and network unavailability
Date: Tue, 13 Apr 2004 15:06:28 +0200	[thread overview]
Message-ID: <16507.58836.330646.613359@robur.slu.se> (raw)
In-Reply-To: <4075F218.90804@outblaze.com>



Christopher Chan writes:

 > However, I had NAPI enabled in the e100 driver then.
 > 
 > Turning NAPI off for the e100 driver has meant that the box has now been 
 > up several days without any problems under heavy network load.
 > 
 > I have not tried out 2.6.5 with NAPI enabled but 2.6.5 without NAPI 
 > enabled is stable.


 dst cache overflows when garbage collection cannot keep up dst entries
 freed so we exceed max_size. GC is run after gc_min_interval and eventually 
 a RCU delay which we have discussed here and are looking into now.

 So if you increase your network performance/load for any reason so more 
 dst entries are freed you can reach the overflow threshold. This is probably 
 what happens for you with NAPI driver.

 You can try to decrease gc_min_interval a bit but if you are unlucky you 
 have run into RCU problem as well. There is one experimental patch that 
 seems help.

 Tuning just to avoid dst cache overflows can mean you sacrifice a lot of
 network performance. Anyway monitor your route cache to start with. There 
 is interesting stats in /proc/net/rt_cache_stat. The rtstat utility can
 be handy parsing it.

 Cheers.
						--ro
 
 

      reply	other threads:[~2004-04-13 13:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-09  0:45 2.6.4 e100 NAPI - dst cache overflow and network unavailability Christopher Chan
2004-04-13 13:06 ` Robert Olsson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16507.58836.330646.613359@robur.slu.se \
    --to=robert.olsson@data.slu.se \
    --cc=cchan@outblaze.com \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).