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
prev parent 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).