Dariush Debian Diary

The only place where the large route cache seems to make sense is for larger servers that are servicing internet connections from many sites. Since the cache is completely flushed every 10 minutes by default, the above machine would have to be adding 55,924 routes per second that were ideally distrbuted throughout the hash space to even fill every bucket. The patch I am proposing is as follows. For the sites that need larger route hashes, they can use the rhash_entries command line option to set it as desired. (http://lkml.org/lkml/2004/12/9/92) gc_elesticity can best be described as the average bucket depth the kernel will accept before it starts expiring route hash entries. This will help maintain the upper limit of active routes. echo 8 > /proc/sys/net/ipv4/route/gc_elasticity (http://lwn.net/Articles/145406/) gc_thresh is another limiting factor in controlling how much RAM your policy routing will eat up. This number cannot be greater than the rhash_entries kernel parameter. As a rule of thumb, set your rhash_entries parameter REALLY high(mine is 2.4million) and control your running limit with gc_thresh. echo 1048576 > /proc/sys/net/ipv4/route/gc_thresh (http://lwn.net/Articles/145406/) IN:Hits are cache hits yes? Tot, are the total number of flows created since we last looked at the total flow count, correct? What would cause a packet to drop in the network stack and thus showup in /proc/net/softnet_stat?

| | | 2007.01.06-20:36.00