IPFW In-Kernel NAT vs PF NAT Performance

[Lev Serebryakov]

On 19.03.2020 9:42, Eugene Grosbein wrote:

>>> 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.
 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) ?
> 
> 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".

-- 
// Lev Serebryakov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20200319/37ec8c93/attachment-0001.sig>