Hi,
I've been playing around a little trying to improve the performance
of iptables connectiontracking and in one test (flood with random source
ip's) I noticed that there are alot of searches in the routingcache
(this is because of all the cachemisses). this second search in
rt_intern_hash() isn't needed on UP AFAIK. No other cpu can insert entries
in the routingcache while we prepare the new entry to be inserted.
And it fixes what I think is a small bug on SMP. We dereference
rt_hash_table[hash].chain before taking the lock. what if it changes
before we start the search, ie. we have to wait for the lock and when we
get to run it's been changed by another cpu.
--- linux-2.4.18-pre3-NAPI.orig/net/ipv4/route.c Sun Jan 13 20:06:47 2002
+++ linux-2.4.18-pre3-NAPI/net/ipv4/route.c Sat Jan 19 19:35:36 2002
@@ -605,9 +605,11 @@
int attempts = !in_softirq();
restart:
- rthp = &rt_hash_table[hash].chain;
-
write_lock_bh(&rt_hash_table[hash].lock);
+
+#ifdef CONFIG_SMP
+ rthp = &rt_hash_table[hash].chain;
+
while ((rth = *rthp) != NULL) {
if (memcmp(&rth->key, &rt->key, sizeof(rt->key)) == 0) {
/* Put it first */
@@ -627,7 +629,7 @@
rthp = &rth->u.rt_next;
}
-
+#endif
/* Try to bind route to arp only if it is output
route or unicast forwarding path.
*/
/Martin
Never argue with an idiot. They drag you down to their level, then beat you
with experience.
|