From: Simon Kirby <sim@netnation.com>
To: Robert Olsson <Robert.Olsson@data.slu.se>, netdev@oss.sgi.com
Subject: Re: Route cache performance
Date: Tue, 8 Mar 2005 17:45:16 -0800 [thread overview]
Message-ID: <20050309014516.GA806@netnation.com> (raw)
In-Reply-To: <16940.9990.975632.115834@robur.slu.se>
On Mon, Mar 07, 2005 at 11:03:50AM +0100, Robert Olsson wrote:
> FYI. The preroute12 was incomplete... There is a number 13.
Hi Robert,
Interesting patch! I haven't had a chance to try it yet, but I have
been thinking about this sort of approach for some time.
I'm wondering, though, if this patch would ever be accepted upstream.
The preroute patches make it now require a full slow route lookup
before checking the route cache, right? Eg: ip_route_input() is
replaced with a call to ip_route_input_nohash() which then might fall
back on ip_route_input() which checks the route cache. The nohash
function, however, still appears to have to do the full fib_lookup()
which is the same as doing at least one slow route lookup for every
packet.
The random src/dst DoS case really kills the route cache because of the
rehashing, locking, and memory allocation and freeing. I see that the
RCU lists and locking now makes it very difficult to recycle the entries,
so I think this patch is probably the right idea for now (although the
route cache should probably still be optimized where possible).
I was wondering if instead it makes sense to still check the route cache
first, but insert the bypass code as in ip_route_input_nohash() between
where the slow route lookup is done and the dst cache entry is created.
In other words:
- The route cache is checked first. Entries in the route cache will
continue immediately as they do now.
- Entries not in the route cache will trigger a slow route lookup as they
do now.
- Routes which are "INPUT" or "OUTPUT" routes (eg: in or out of the local
machine) will be added to the route cache as normal.
- Routes which are "FORWARD" routes will NOT be added to the route cache
(and thus fall back to "slow" lookups up each time as with the preroute
patch). These slow lookups will be faster than maintaining route cache
entries for these packets which we don't ever learn an MSS for anyway.
In fact, a heuristic could maybe be added to make the route cache bypass
conditional so that it only occurs when the table is full or there are
too many cache misses, or something. This would maintain the route cache
performance in normal conditions but remove the route cache overhead in
spoofed src/dst type DoS loads that kill us today.
My guess is this would be an even simpler patch as some of the preroute
patch is a duplication of ip_route_input_slow() that has to happen in
this case anyway.
Simon-
next parent reply other threads:[~2005-03-09 1:45 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20050301220743.GF2554@netnation.com>
[not found] ` <16940.9990.975632.115834@robur.slu.se>
2005-03-09 1:45 ` Simon Kirby [this message]
2005-03-09 12:05 ` Route cache performance Robert Olsson
2005-08-15 21:38 Simon Kirby
2005-08-16 2:23 ` Eric Dumazet
2005-08-23 19:08 ` Simon Kirby
2005-08-23 19:56 ` Robert Olsson
2005-08-24 0:01 ` Simon Kirby
2005-08-24 3:50 ` Robert Olsson
2005-08-25 18:11 ` Simon Kirby
2005-08-25 20:05 ` Alexey Kuznetsov
2005-08-25 21:22 ` Simon Kirby
2005-08-26 11:55 ` Alexey Kuznetsov
2005-08-26 19:49 ` Robert Olsson
2005-09-06 23:57 ` Simon Kirby
2005-09-07 1:19 ` Alexey Kuznetsov
2005-09-07 15:03 ` Robert Olsson
2005-09-07 16:55 ` Simon Kirby
2005-09-07 17:21 ` Robert Olsson
2005-09-07 14:45 ` Robert Olsson
2005-09-07 16:28 ` Simon Kirby
2005-09-07 16:49 ` Robert Olsson
2005-09-07 16:57 ` Simon Kirby
2005-09-07 19:59 ` Alexey Kuznetsov
2005-09-13 22:14 ` Simon Kirby
2005-09-14 8:04 ` Robert Olsson
2005-09-17 0:28 ` Simon Kirby
2005-09-17 9:04 ` Martin Josefsson
2005-09-17 15:17 ` jamal
2005-09-15 21:04 ` Alexey Kuznetsov
2005-09-15 21:30 ` Robert Olsson
2005-09-15 22:21 ` Alexey Kuznetsov
2005-09-16 12:18 ` Robert Olsson
2005-09-16 19:04 ` Alexey Kuznetsov
2005-09-16 19:22 ` Ben Greear
2005-09-16 19:57 ` Robert Olsson
-- strict thread matches above, loose matches on Subject: below --
2005-08-24 16:06 Simon Kirby
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=20050309014516.GA806@netnation.com \
--to=sim@netnation.com \
--cc=Robert.Olsson@data.slu.se \
--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).