route cache DoS testing and softirqs
From: Dipankar Sarma
Date: Mon Mar 29 2004 - 13:53:16 EST
Robert Olsson noticed dst cache overflows while doing DoS stress testing in a
2.6 based router setup a few months and davem, alexey, robert and I
have been discussing this privately since then (198 mails, no less!!).
Recently, I set up an environment to test Robert's problem and have
been characterizing it. My setup is -
pktgen box --- in router out --
eth0 eth0 <-> dumm0
10.0.0.1 10.0.0.2 18.104.22.168
The router box is a 2-way P4 xeon 2.4 GHz with 256MB memory. I use
Robert's pktgen script -
echo "Configuring $PGDEV"
pgset "flag IPDST_RND"
pgset "dst_min 22.214.171.124"
pgset "dst_max 126.96.36.199"
pgset "flows 32768"
pgset "flowlen 10"
With this, wthin a few seconds of starting pktgen, I get dst cache
overflow messages. I use the following instrumentation patch
to look at what's happening -
I tried both vanilla 2.6.0 and 2.6.0 + throttle-rcu patch which limits
RCU to 4 updates per RCU tasklet. The results are here -
This graph shows the maximum grace period during ~4ms time buckets on x-axis.
Couple of things are clear from this -
1. RCU grace periods of upto 300ms are seen. 300ms + 100Kpps packet
amounts to about 30000 pending dst entries which result in route cache
2. throttle-rcu is only marginally better (10% less worst case grace period).
So, what causes RCU to stall for 300ms odd time ? I did some measurements
using the following patch -
It applies on top of the 15-rcu-debug patch. This counts the number of
softirqs (in effect and approximation) during ~4ms time buckets. The
result is here -
The rcu grace period spikes are always accompanied by softirq frequency
spikes. So, this indicates that it is the large number of quick-running
softirqs that cause userland starvation which in turn result in RCU
delays. This raises a fundamental question - should we work around
this by providing a quiescent point at the end of every softirq handler
(giving softirqs its own RCU mechanism) or should we address a wider
problem, the system getting overwhelmed by heavy softirq load, and
try to implement a real softirq throttling mechanism that balances
Robert demonstrated to us sometime ago with a small
timestamping user program to show that it can get starved for
more than 6 seconds in his system. So userland starvation is an
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/