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
signature.asc
Description: OpenPGP digital signature
