Re: [PATCH net 2/5] netfilter: conntrack: sanitize table size default settings

From: Florian Westphal <fw@strlen.de>
To: Vincent Pelletier <plr.vincent@gmail.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
	netfilter-devel@vger.kernel.org, davem@davemloft.net,
	netdev@vger.kernel.org, kuba@kernel.org,
	Florian Westphal <fw@strlen.de>
Subject: Re: [PATCH net 2/5] netfilter: conntrack: sanitize table size default settings
Date: Thu, 31 Mar 2022 17:21:49 +0200	[thread overview]
Message-ID: <20220331152149.GA5024@breakpoint.cc> (raw)
In-Reply-To: <20220331145909.085a0f30@gmail.com>

Vincent Pelletier <plr.vincent@gmail.com> wrote:
> On Fri,  3 Sep 2021 18:30:17 +0200, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > From: Florian Westphal <fw@strlen.de>
> > 
> > conntrack has two distinct table size settings:
> > nf_conntrack_max and nf_conntrack_buckets.
> > 
> > The former limits how many conntrack objects are allowed to exist
> > in each namespace.
> > 
> > The second sets the size of the hashtable.
> > 
> > As all entries are inserted twice (once for original direction, once for
> > reply), there should be at least twice as many buckets in the table than
> > the maximum number of conntrack objects that can exist at the same time.
> > 
> > Change the default multiplier to 1 and increase the chosen bucket sizes.
> > This results in the same nf_conntrack_max settings as before but reduces
> > the average bucket list length.
> [...]
> >  		nf_conntrack_htable_size
> >  			= (((nr_pages << PAGE_SHIFT) / 16384)
> >  			   / sizeof(struct hlist_head));
> > -		if (nr_pages > (4 * (1024 * 1024 * 1024 / PAGE_SIZE)))
> > -			nf_conntrack_htable_size = 65536;
> > +		if (BITS_PER_LONG >= 64 &&
> > +		    nr_pages > (4 * (1024 * 1024 * 1024 / PAGE_SIZE)))
> > +			nf_conntrack_htable_size = 262144;
> >  		else if (nr_pages > (1024 * 1024 * 1024 / PAGE_SIZE))
> > -			nf_conntrack_htable_size = 16384;
> [...]
> > +			nf_conntrack_htable_size = 65536;
> 
> With this formula, there seems to be a discontinuity between the
> proportional and fixed regimes:
> 64bits: 4GB/16k/8 = 32k, which gets bumped to 256k
> 32bits: 1GB/16k/4 = 16k, which gets bumped to 64k
> 
> Is this intentional ?

There is no science here.  This tries to pick a sane default setting,
thats all. Its not possible to pick one that works for everyone and everything.

32bit kernel can't access more than 1GB so I did not want to
increase that too much.

These are default settings, users should be free to pick any value they
like/need.