[Top] [All Lists]

Re: route cache DoS testing and softirqs

To: Andrea Arcangeli <andrea@xxxxxxx>
Subject: Re: route cache DoS testing and softirqs
From: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Tue, 30 Mar 2004 23:29:44 +0200
Cc: Dipankar Sarma <dipankar@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, Robert Olsson <Robert.Olsson@xxxxxxxxxxx>, "Paul E. McKenney" <paulmck@xxxxxxxxxx>, Dave Miller <davem@xxxxxxxxxx>, Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxx>
In-reply-to: <20040330204731.GG3808@dualathlon.random>
References: <> <20040329222926.GF3808@dualathlon.random> <> <> <20040330204731.GG3808@dualathlon.random>
Sender: netdev-bounce@xxxxxxxxxxx
Andrea Arcangeli writes:

 > I see what's going on now, yes my patch cannot help. the workload is
 > simply generating too much hardirq load, and it's like if we don't use
 > softirq at all but that we process the packet inside the hardirq for
 > this matter. As far as RCU is concerned it's like if there a no softirq
 > at all but that we process everything in the hardirq.
 > so what you're looking after is a new feature then:
 > 1) rate limit the hardirqs
 > 2) rate limit only part of the irq load (i.e. the softirq, that's handy
 >    since it's already splitted out) to scheduler-aware context (not
 >    inside irq context anymore)
 > 3) stop processing packets in irqs in the first place (NAPI or similar)


 No Andrea it pure softirq workload. Interfaces runs with irq disabled 
 at this load w. NAPI. Softirq's are run from spin_unlock_bh etc when 
 doing route lookup and GC. And the more fine-grained locking we do the 
 the more do_softirq's are run.


<Prev in Thread] Current Thread [Next in Thread>