On Tue, Jun 25, 2002 at 05:13:02PM +0200, Balazs Scheidler wrote: > On Tue, Jun 25, 2002 at 04:17:54PM +0200, Jozsef Kadlecsik wrote: > > On Tue, 25 Jun 2002, Jean-Michel Hemstedt wrote: > > > > The book-keeping overhead is at least doubled compared to the > > > > conntrack-only case - this explains pretty well the results you got. > > > > > > what do you mean by 'book-keeping' ? > > > Does NAT do a lookup even if there are no rules? > > > > I have to write again: even if there are no any rules, NULL > > mapping happens and new connections must be put into both nat hashes. > > This should not explain the performance degradation others found. If no > rules are found in the table, the conntrack entry is added to the NAT > hashes. (place_in_hashes() function), this involves adding the entry to two > linked lists (changes two pointers per list), and then calling do_bindings() > which does nothing (num_manips == 0) except for calling helpers, which > should be none, if helper modules are not loaded. > > Adding entries to the NAT hashes doesn't involve memory allocation (NAT info > is stored in ip_conntrack), therefore I don't see the reason for the 50% > performance decrease.
think about the lock contention on SMP system. The 'null binding' approach for nat (and for example, that nat helpers are called for connections with 'null binding') is a poor design. I've recently did some testing which try to avoid the null binding, but as I'm not entirely sure they don't break something else I haven't been releasing them yet. > Bazsi -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
