netdev
[Top] [All Lists]

Re: route cache DoS testing and softirqs

To: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Subject: Re: route cache DoS testing and softirqs
From: Dipankar Sarma <dipankar@xxxxxxxxxx>
Date: Wed, 31 Mar 2004 13:06:30 +0530
Cc: Andrea Arcangeli <andrea@xxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, "Paul E. McKenney" <paulmck@xxxxxxxxxx>, Dave Miller <davem@xxxxxxxxxx>, Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxx>
In-reply-to: <16489.59080.303710.986410@xxxxxxxxxxxx>
References: <20040329184550.GA4540@xxxxxxxxxx> <20040329222926.GF3808@xxxxxxxxxxxxxxxxx> <20040330144324.GA3778@xxxxxxxxxx> <20040330195315.GB3773@xxxxxxxxxx> <20040330204731.GG3808@xxxxxxxxxxxxxxxxx> <16489.59080.303710.986410@xxxxxxxxxxxx>
Reply-to: dipankar@xxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Tue, Mar 30, 2004 at 11:29:44PM +0200, Robert Olsson wrote:
> 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.

Not lookup, we don't take the lock in lookup. Probably route 
insertions which will happen very frequently in this case.

Thanks
Dipankar

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