Date: Thu, 19 Mar 2020 14:19:55 +0300 From: Lev Serebryakov <lev@FreeBSD.org> To: Eugene Grosbein <eugen@grosbein.net>, 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: <d91c3fbe-2573-f31a-b21f-ccb3517f061a@FreeBSD.org> In-Reply-To: <c125ce0b-05bb-0a99-4ec5-24b74d6e606a@grosbein.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8z5bs69UCsV8muV4i3FtMd5xlK67ZrRIi Content-Type: multipart/mixed; boundary="OQFcyCRqscLGE3Eoo6jEabHsJUNeEIDxa" --OQFcyCRqscLGE3Eoo6jEabHsJUNeEIDxa Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 19.03.2020 9:42, Eugene Grosbein wrote: >>> I=E2=80=99d 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 the= m >> (easy fixable, but you need patch sources and rebuild kernel/module) i= s >> 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. >=20 > It's really 4001 that is (and sould be) prime number. Oh, yes, I've forgot this detail. > Don't you think that now as ipfw nat builds libalias in kernel context,= > it could scale with maxusers (sys/systm.h) ? >=20 > Something like (4001 + (maxusers-32)*8) so it grows with amount of phys= ical 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". --=20 // Lev Serebryakov --OQFcyCRqscLGE3Eoo6jEabHsJUNeEIDxa-- --8z5bs69UCsV8muV4i3FtMd5xlK67ZrRIi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE+W0coLX0MYtnSzMK6rA8WL/cR48FAl5zVVtfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEY5 NkQxQ0EwQjVGNDMxOEI2NzRCMzMwQUVBQjAzQzU4QkZEQzQ3OEYACgkQ6rA8WL/c R4++pRAAqMir1CampcJk5VTS4qV3FtSuhv9l1zAIVXLnoMY09AHb+0+kK8wShfZt eq+M53G1+JsD9YY9OKzpR71Hbsh+H032HdZH8cn+Os6i2u9gDRLkQFZTMc/VhKer dOhNDsAo4lml7xCB0s2pQcwWFXctcifzhYto/G9yZ2qCcbuLt7a/v/Mlktiv2rF0 xPl54QiGql21mIRs8FiWPnPVwYfdhu4prtG8JjdZzKT2RnHvk6+6109LIzlU3P6j rn/KQfrCjybYh0Vm4WzcMTMTSX27G9BRlTxdD01gsUP0YdcSFPJ0tGAxxDmtgzeh +LGw8Nm/gVDvQ5WtmWu7Er+0/qJSnofQyI7TLl9af20hyK8bcgwTX3ldnBipMgua tkKTCK/TjxjRY3kU6A7On1tVhQefCUZurlll5sMdcItS7dBioGdbdMUOgeKlK8mh 4XTHgVcC1pD2FBn//dr5iqBUA6MqoCZl0Inw+X9q9iVJSUKBZazsWqBz3EVaLOvH b3LcAc1FvtqCiSSuRocV5Dh4EigXChCs0/oU545DjebK2HPH4t7dnyOAKra6WE01 mfHpdozI5CvP4u6RTMiHQHrOfEvknQGzG9FUxDxUqS47RObLffVMXaoWsVV+hxBJ NY3/RVRzRrsTUQXNlKpLNTqTGCQ264L52bAAFl48FCWFuI2EIhE= =aDd3 -----END PGP SIGNATURE----- --8z5bs69UCsV8muV4i3FtMd5xlK67ZrRIi--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d91c3fbe-2573-f31a-b21f-ccb3517f061a>