Date: Sat, 4 Aug 2018 19:02:49 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Kristof Provost <kp@FreeBSD.org> Cc: Gleb Smirnoff <glebius@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r336221 - head/sys/net Message-ID: <20180805020249.GL2884@funkthat.com> In-Reply-To: <25795E0A-A362-44B2-AC5A-573442FC256D@FreeBSD.org> References: <201807121635.w6CGZZAN046919@repo.freebsd.org> <20180803230405.GI420@FreeBSD.org> <25795E0A-A362-44B2-AC5A-573442FC256D@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kristof Provost wrote this message on Sat, Aug 04, 2018 at 12:49 +0200: > On 4 Aug 2018, at 1:04, Gleb Smirnoff wrote: > > On Thu, Jul 12, 2018 at 04:35:35PM +0000, Kristof Provost wrote: > > K> Author: kp > > K> Date: Thu Jul 12 16:35:35 2018 > > K> New Revision: 336221 > > K> URL: https://svnweb.freebsd.org/changeset/base/336221 > > K> > > K> Log: > > K> pf: Increate default state table size > > K> > > K> The typical system now has a lot more memory than when pf was > > new, and is also > > K> expected to handle more connections. Increase the default size of > > the state > > K> table. > > K> Note that users can overrule this using 'set limit states' in > > pf.conf. > > K> > > K> From OpenBSD: > > K> The year is 2018. > > K> Mercury, Bowie, Cash, Motorola and DEC all left us. > > K> Just pf still has a default state table limit of 10000. > > K> Had! Now it's a tiny little bit more, 100k. > > K> lead guitar: me > > K> ok chorus: phessler theo claudio benno > > K> background school girl laughing: bob > > > > For FreeBSD it would also make sense to bump hash sizes along with > > this change. > > > Yeah, Olivier did some benchmarking work around this: > https://github.com/ocochard/netbenches/blob/master/Atom_C2758_8Cores-Chelsio_T540-CR/pf-states_hashsize/results/fbsd12-head.r332390/README.md > > He found a roughly 10% increase in throughput by increasing the hash > size to 256K. > I???ve been thinking about making the hash size dynamically configurable > (so we could calculate it based in the state limit, rather than expect > users to tune this manually), but that???s probably not going to get > done any time soon. Yes, this would be best... Also, tests on non-amd64 hardware would be good as well... > I???ll see about increasing the default (although perhaps not to 256K, > because if my math is right that???s cost us ~20MB of memory) soon, > because that???s mostly a quick win. I can see a default of maybe 64k (giving an average of just under 2 per bucket). IMO if you have that busy of a firewall, some tuning should be expected. Also, I don't know the hash used, but another option is to use a non-power of 2 hash... Increasing the memory required on smaller systems and not making sure it's documented how to save that memory is a bad idea... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180805020249.GL2884>