Messages in this thread | | | Date | Wed, 9 Jun 1999 01:27:51 +0300 (EEST) | From | Julian Anastasov <> | Subject | Re: [Masq-dev] Use daddr and dport as hash keys for faster masq redirector! |
| |
On Sun, 6 Jun 1999, John D. Hardin wrote:
> erm, no. A more flexible and general solution would be to add a > destination lookup table as well as source and masq, and have the > ability to look up by hashing the source address and port from inbound > packets into the destination lookup table.
Yes, I agree that dest table will be useful but why to add additional tables. We don't need each protocol to use it's own table. Let it use it's own keys for ip_masq_m_tab and ip_masq_s_tab. I again return to my example where connections are created outside firewall to virtual web server for example and then redirected to local web servers. If we add additional dest lookup table we will faster create entries and search entries by daddr&dport from inbound packets but we will spend too much time in ip_masq_unhash - we must unlink entry from each table but all entries in ip_masq_m_tab and ip_masq_s_tab are hashed by maddr/mport and saddr/sport, i.e. they are all linked on same row. For example if we receive 1000 connections per second to our virtual server and we serve these connections for 10 seconds and time-wait 120 sec we have 1000*(10+120) entries. Search in dtable will be fast but we must unhash 1000 entries per second searching in ip_masq_m_tab and ip_masq_s_tab where we must remove 1 entry from 130000 => we must compare data for 65000 average per second (expect newly created connections in top of list followed by old connections, i.e. 65000-130000). So, we need faster access not just when searching in dest table (if we decide to add such table) but faster access to other tables. Yes, we don't have 65000 times faster access but for short connections where we have to transmit 50KB for example (assuming acks and 1500 bytes per packet) we have to:
- create entry (faster) - receive and lookup for ~70 packets (faster) - remove entry (slow - search 65000 entries)
I thing using IP_MASQ_F_MPORT as flag what to use as key for these two tables allows both normal and reverse masq connections to be handled faster for these operations:
- add entry to table (ip_masq_hash) - lookup by values from inbound packets (__ip_masq_in_get and __ip_masq_out_get) - remove entry from table (ip_masq_unhash)
So, I thing:
- we don't need additional tables (more than 2) - we need proper keys - we need fast lookup to any table for any entry - normal and reverse connections can coexist in all tables (ip_masq_m_tab and ip_masq_s_tab) and to have fast any kind of access (create/lookup by data/remove) - any protocol can use these 2 tables if IP_MASQ_F_MPORT is used (set or unset), i.e. if ip_masq_new() is used. - IP_MASQ_F_MPORT distinguishes between normal and reverse connections, i.e. if daddr/dport are useful - we can ignore IP_MASQ_F_MPORT for TCP and always to hash using daddr and dport (even for normal masq connections) but this is another variant (may be not good). - yes, we can skip this first check in ip_masq_in_get for entries with IP_MASQ_F_MPORT flag set if mport is in PORT_MASQ_BEGIN..PORT_MASQ_END range (to be done)
J. Anastasov
- 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/
| |