Date: Thu, 19 Mar 2020 13:42:01 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: lev@FreeBSD.org, Kristof Provost <kp@FreeBSD.org>, Neel Chauhan <neel@neelc.org> Cc: freebsd-net@freebsd.org Subject: Re: IPFW In-Kernel NAT vs PF NAT Performance Message-ID: <c125ce0b-05bb-0a99-4ec5-24b74d6e606a@grosbein.net> In-Reply-To: <cb87cc92-59ff-119e-be43-41d51b94f7e9@FreeBSD.org> References: <fc638872b9bdf14c13e2d6c13e698d1e@neelc.org> <F154BCBA-4079-48CA-ACE9-F01FBCBD53D0@FreeBSD.org> <cb87cc92-59ff-119e-be43-41d51b94f7e9@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c125ce0b-05bb-0a99-4ec5-24b74d6e606a>