From owner-freebsd-net@freebsd.org Thu Mar 19 06:42:30 2020 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 169A227CE9F for ; Thu, 19 Mar 2020 06:42:30 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48jclm4BX6z4Cb9; Thu, 19 Mar 2020 06:42:28 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 02J6gBjm054827 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Mar 2020 06:42:15 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: lev@FreeBSD.org Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 02J6g9dK002737 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 Mar 2020 13:42:09 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: IPFW In-Kernel NAT vs PF NAT Performance To: lev@FreeBSD.org, Kristof Provost , Neel Chauhan References: Cc: freebsd-net@freebsd.org From: Eugene Grosbein Message-ID: Date: Thu, 19 Mar 2020 13:42:01 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 48jclm4BX6z4Cb9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.57 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.62)[-0.623,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; IP_SCORE(-1.85)[ip: (-5.12), ipnet: 2a01:4f8::/29(-2.56), asn: 24940(-1.55), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 06:42:30 -0000 18.03.2020 21:25, Lev Serebryakov wrote: > On 18.03.2020 9:17, Kristof Provost wrote: > >>> Which firewall gives better performance, IPFW's In-Kernel NAT or PF NAT? I am dealing with 1000s of concurrent connections but browsing-level-bandwidth at once with Tor. >>> >> I’d expect both ipfw and pf to happily saturate gigabit links with NAT, even on quite modest hardware. >> Are you sure the NAT code is the bottleneck? > ipfw nat is very slow, really. There are many reasons, and one of them > (easy fixable, but you need patch sources and rebuild kernel/module) is > that `libalias` uses only 4096 buckets in state hashtable by default. So > it could saturate 1GBps link if you have 10 TCP connections, but it > could not saturate 100Mbit if your have, say, 100K UDP streams. It's really 4001 that is (and sould be) prime number. Don't you think that now as ipfw nat builds libalias in kernel context, it could scale with maxusers (sys/systm.h) ? Something like (4001 + (maxusers-32)*8) so it grows with amount of physical memory and is kept small for low-memory systems.