On Sat, 2010-04-24 at 22:11 +0200, Eric Dumazet wrote: > > > Monday or Tuesdag I'll do a test setup with some old HP380 G4 machines to > > see if I can reproduce the DDoS attack senario. And see if I can get > > it into to lookup loop. > > Theorically a loop is very unlikely, given a single retry is very > unlikly too. > > Unless a cpu gets in its cache a corrupted value of a 'next' pointer. > ... > > With same hash bucket size (300.032) and max conntracks (800.000), and > after more than 10 hours of test, not a single lookup was restarted > because of a nulls with wrong value. So fare, I have to agree with you. I have now tested on the same type of hardware (although running a 64-bit kernel, and off net-next-2.6), and the result is, the same as yours, I don't see a any restarts of the loop. The test systems differs a bit, as it has two physical CPU and 2M cache (and annoyingly the system insists on using HPET as clocksource). Guess, the only explanation would be bad/sub-optimal hash distribution. With 40 kpps and 700.000 'searches' per second, the hash bucket list length "only" need to be 17.5 elements on average, where optimum is 3. With my pktgen DoS test, where I tried to reproduce the DoS attack, only see a screw of 6 elements on average. > I can setup a test on a 16 cpu machine, multiqueue card too. Don't think that is necessary. My theory was it was possible on slower single queue NIC, where one CPU is 100% busy in the conntrack search, and the other CPUs delete the entries (due to early drop and call_rcu()). But guess that note the case, and RCU works perfectly ;-) > Hmm, I forgot to say I am using net-next-2.6, not your kernel version... I also did this test using net-next-2.6, perhaps I should try the version I use in production... -- Med venlig hilsen / Best regards Jesper Brouer ComX Networks A/S Linux Network Kernel Developer Cand. Scient Datalog / MSc.CS Author of http://adsl-optimizer.dk LinkedIn: http://www.linkedin.com/in/brouer -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
