linux-kernel - Re: [PATCH] net: compute a more reasonable default ip6_rt_max

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1338124708.3670.11.camel@edumazet-glaptop>
Date:	Sun, 27 May 2012 15:18:28 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Arun Sharma <asharma@...com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: compute a more reasonable default ip6_rt_max_size

On Sat, 2012-05-26 at 20:54 -0700, Arun Sharma wrote:
> On 5/25/12 8:39 PM, Eric Dumazet wrote:
> >
> > But your patch is not a  "modest increase", so whats the deal ?
> >
> > A modest increase would be 8192 instead of 4096, regardless of RAM size.
> >
> 
> Yes - 8192 solves our immediate problem, but I was worrying that the 
> problem might resurface as ipv6 adoption becomes more widespread.
> 

Going from 4096 to 8192 is modest increase. If you put 65536, it should
be enough for the next years.

Your patch was increasing 4096 to 524288 (for 2GB of ram), which sounds
not modest at all.

> We were testing a pre-3.0 kernel that didn't have Dave's DST_NOCOUNT 
> patch. Will retest with that patch applied.

Good

> 
>  > More over, a boot parameter to tweak it is absolutely not needed
> 
> Agreed. Will remove that part.
> 
> Still not sure why you'd like to go for one size regardless of 
> totalram_pages.

Because size of IPv6 route table is not depending on RAM size, but on
number or IPv6 routes.

A router runs a piece of software complex enough to be able to adjust
the limit when needed, don't you think so ?

Your patch basically removes the whole idea of having a limit in the
first place. Why do we have a limit if you set it to four order of
magnitudes bigger than necessary ?




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/