Vincent Pelletier <plr.vincent@xxxxxxxxx> wrote: > On Fri, 3 Sep 2021 18:30:17 +0200, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > From: Florian Westphal <fw@xxxxxxxxx> > > > > 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.
