On Mon, Oct 04, 2004 at 12:17:59PM -0700, David S. Miller wrote:
> Ok I started playing with this, here is what I have currently.
> 2) Missing symbol exports for the new interfaces modules can use,
oh, sorry. I just linked atm,decnet and ipv6 static so far :(
> 3) Delete instead of "#if 0" out the now totally unused code
> inside of net/atm/clip.c
oops, that slipped through. embarrassing.
> We need to test and verify this patch a lot before I can toss
> such a big thing over to Marcelo, but I definitely intend to
> send this to him.
sure, I am well aware of that. If it helps, at least the IPv4 part will
see some serious deployment after it has passed the Astaro QA :)
I'll keep you posted about that.
One additional note:
If we go back to the initial reason for all those modifications, it was
deployment in large networks. The gc_thresh3 default of 1k is very
small, even if you have only 4 interfaces with /24, you will already max
out this default.
Now that the hash distribution is better, and the table resized
dynamically, we scale better with large neighbour caches.
I was thinking of registering with some notifiers and tuning gc_thresh3
automatically to be at least as large as the theoretical number of
immediate neigbhours. At least for multiple /24 and /16 I think this is
As soon as we go further up (/8 or ipv6) the limit basically becomes
'unlimited', since we won't be able to receive 2^24 arp-causing packets
per second anyway.
Or be even less conservative and say: there is no limit for neighbour
cache entries? You mentioned that *BSD didn't have a limit, IIRC.
- Harald Welte <laforge@xxxxxxxxxxxx> http://www.gnumonks.org/
Programming is like sex: One mistake and you have to support it your lifetime
Description: Digital signature