From owner-svn-src-head@freebsd.org Sun Aug 5 02:02:51 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6760B105D144; Sun, 5 Aug 2018 02:02:51 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1AA773671; Sun, 5 Aug 2018 02:02:50 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w7522nYf094392 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Aug 2018 19:02:49 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w7522nZ8094391; Sat, 4 Aug 2018 19:02:49 -0700 (PDT) (envelope-from jmg) Date: Sat, 4 Aug 2018 19:02:49 -0700 From: John-Mark Gurney To: Kristof Provost Cc: Gleb Smirnoff , 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> Mail-Followup-To: John-Mark Gurney , Kristof Provost , Gleb Smirnoff , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201807121635.w6CGZZAN046919@repo.freebsd.org> <20180803230405.GI420@FreeBSD.org> <25795E0A-A362-44B2-AC5A-573442FC256D@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25795E0A-A362-44B2-AC5A-573442FC256D@FreeBSD.org> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sat, 04 Aug 2018 19:02:49 -0700 (PDT) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2018 02:02:51 -0000 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."