On Tue, Mar 19, 2002 at 09:49:20AM +0100, Patrick Schaaf wrote: > Hi Harald, > > > > On machines where I expect many connections, I'd use a hashsize > > > near the number of expected connections, and make conntrack_max > > > only about two times that value. > > > > But this obviously only helps if the hash function is distributing > > the conntrack entries equally among the hash buckets. I wouldn't be > > so sure if this really does happen when the hash becomes wider than a > > certain point. > > In theory, a good hash function would distribute well independant of > the size of the bucket array. > > In practise, theory is theory... > > I agree that the hash function needs scrutiny. Do you (or somebody else > here) have a good collection of real world /proc/net/ip_conntrack excerpts, > maybe coming from the development of ctnetlink? I'll cook up a "hash > occupation simulator" for user level, where you can pipe in a conntrack > table, and get reports about the distribution of chain sizes.
The problem is that reading out /proc/net/ip_conntrack is slow and cpu-burning as hell and I don't want to do this on firewalls with large numbers of conntrack entries. I'd rather like to have this information to be gathered at runtime within the kernel, where one could read out the current hash occupation via /proc or some ioctl. > As I don't run realworld conntracking firewalls with lots of connections > (I'm using the stuff almost exclusively on servers), I need the help of > you all to get good input test data, here. I guess if there is a patch in p-o-m, some people would run a cronjob which extracts this occupation info every minute or so and send a gzipped summary to us. At least I could do this on a bunch of small to medium-sized firewalls, and there certainly are volunteers on the list as well :) > These are all important constraints. However, the problem is not insoluble. > Given a good cryptographic hash (not that I'd want to have SHA or MD5 for > this purpose :-) won't care about such issues. The art is to find a fast > hash function that still is not very sensitive to the inputs. Exactly. > best regards > Patrick -- 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+(*)
