[Top] [All Lists]

Re: Route cache performance under stress

To: "David S. Miller" <davem@xxxxxxxxxx>
Subject: Re: Route cache performance under stress
From: Simon Kirby <sim@xxxxxxxxxxxxx>
Date: Mon, 9 Jun 2003 00:36:44 -0700
Cc: xerox@xxxxxxxxxx, fw@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx, linux-net@xxxxxxxxxxxxxxx
In-reply-to: <20030608.235622.38700262.davem@xxxxxxxxxx>
References: <001501c32e4b$35d67d60$4a00000a@badass> <20030608.230332.48514434.davem@xxxxxxxxxx> <20030609065211.GB20613@xxxxxxxxxxxxx> <20030608.235622.38700262.davem@xxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.4i
On Sun, Jun 08, 2003 at 11:56:22PM -0700, David S. Miller wrote:

> We have to walk the entire destination hash chain _ANYWAYS_ to verify
> that a matching entry has not been put into the cache while we were
> procuring the new one.  During this walk we can also choose a
> candidate rtcache entry to free.

Ah, neat.  I should try reading this stuff. :)

> Something like the patch at the end of this email, doesn't compile
> it's just a work in progress.  The trick is picking TIMEOUT1 and
> Another point is that the default ip_rt_gc_min_interval is
> absolutely horrible for DoS like attacks.  When DoS traffic
> can fill the rtcache multiple times per second, using a GC
> interval of 5 seconds is the worst possible choice. :)

Yes, I've reduced the gc_min_interval to 1, and it has been that way for
some time.  BTW, you may be interested in this old email from Alexey:

(This was back when the GC was limited so much that legitimate traffic
was overflowing the table.  DoS attacks must have been really effective
then. :))


[        Simon Kirby        ][        Network Operations        ]
[     sim@xxxxxxxxxxxxx     ][   NetNation Communications Inc.  ]
[  Opinions expressed are not necessarily those of my employer. ]

<Prev in Thread] Current Thread [Next in Thread>