> The worse case will be if a masq module creates large number of rev
> or normal masq entries with NO_DADDR and/or NO_DPORT flags to same
> maddr and mport or to same saddr and sport and no connection take
> place (flood from outside the firewall to create such inactive
> entries).
And this case isn't too bad either - it's no worse than the current
situation of not having a destination list.
> - we must use d{addr,port} as the only hash keys for
> m_tab only when F_MPORT=1. So, better to use
> d{addr,port}+m{addr,port} as keys for m_tab.
I disagree, still. The d{addr,port} lookup in __ip_masq_in_get()
should find it quickly without having "special case" keying; this
strikes me as an unnecessary complication.
> - using prev link for each table is a way to speedup
> unhash/rehash for entries with value 0 in d{addr,port}
> or s{addr,port},
Why would it hurt other entries? I think it's a win regardless.
I think you're trying to trade clarity and flexibility for memory
footprint. I'd rather see the following lists:
s{addr,port}
d{addr,port}
m{addr,port}
s+d{addr,port}
m+d{addr,port}
...and no "special case" keying. For NO_D* | F_DLOOSE ip_masq_hash()
could simply *not hash* the entry into the destination lists. This
means 10 pointers per ms (each being a doubly-linked list), and two or
five hash operations in ip_masq_hash() depending on the flags. Is this
too expensive?
--
John Hardin KA7OHZ jhardin@wolfenet.com
pgpk -a finger://gonzo.wolfenet.com/jhardin PGP key ID: 0x41EA94F5
PGP key fingerprint: A3 0C 5B C2 EF 0D 2C E5 E9 BF C8 33 A7 A9 CE 76
-----------------------------------------------------------------------
Efficiency can magnify good, but it magnifies evil just as well.
So, we should not be surprised to find that modern electronic
communication magnifies stupidity as *efficiently* as it magnifies
intelligence.
-- Robert A. Matern
-----------------------------------------------------------------------
90 days until 9/9/99
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/