Date: Thu, 19 Mar 2020 18:26:24 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: freebsd-net@freebsd.org Subject: Re: IPFW In-Kernel NAT vs PF NAT Performance Message-ID: <b2811446-c6e1-f903-3af0-c1f5dd3d0f8d@grosbein.net> In-Reply-To: <d91c3fbe-2573-f31a-b21f-ccb3517f061a@FreeBSD.org> References: <fc638872b9bdf14c13e2d6c13e698d1e@neelc.org> <F154BCBA-4079-48CA-ACE9-F01FBCBD53D0@FreeBSD.org> <cb87cc92-59ff-119e-be43-41d51b94f7e9@FreeBSD.org> <c125ce0b-05bb-0a99-4ec5-24b74d6e606a@grosbein.net> <d91c3fbe-2573-f31a-b21f-ccb3517f061a@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
19.03.2020 18:19, Lev Serebryakov wrote: >> 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. > IMHO, "maxusers" us useless now. It must be sysctl, as size of dynamic > state table of IPFW itself. I have low-memory system where WHOLE memory > is dedicated to firewall/nat, for example. I need really huge tables > (131101) to make it work "bad" and not "terrible". Sure, dedicated sysctl. I mean, its default value should be auto-tuned based on maxusers that grows with installed RAM by default.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b2811446-c6e1-f903-3af0-c1f5dd3d0f8d>