[Top] [All Lists]

Re: route cache DoS testing and softirqs

To: Andrea Arcangeli <andrea@xxxxxxx>
Subject: Re: route cache DoS testing and softirqs
From: Dipankar Sarma <dipankar@xxxxxxxxxx>
Date: Wed, 31 Mar 2004 02:36:48 +0530
Cc: 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@xxxxxxxxxxxxxxxxx>
References: <20040329184550.GA4540@xxxxxxxxxx> <20040329222926.GF3808@xxxxxxxxxxxxxxxxx> <20040330144324.GA3778@xxxxxxxxxx> <20040330195315.GB3773@xxxxxxxxxx> <20040330204731.GG3808@xxxxxxxxxxxxxxxxx>
Reply-to: dipankar@xxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Tue, Mar 30, 2004 at 10:47:32PM +0200, Andrea Arcangeli wrote:
> 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)

There were a number of somewhat ugly softirq limiting patches that
Robert tried out (not spitting them to scheduler-aware context) and some 
combination of that worked well in Robert's setup. I will see if I can 
revive that. That said, we would need to find out how badly we affect network
performance with that thing.

> 3) stop processing packets in irqs in the first place (NAPI or similar)
> however I start to think they can be all wrong, and that rcu is simply
> not suitable for purerely irq usages like this. w/o rcu there would be
> no need of the scheduler keeping up with the irq load, and in some usage
> I can imagine that it is a feature to prioritize heavily on the
> irq load vs scheduler-aware context.

Not necessarily, we can do a call_rcu_bh() just for softirqs with 
softirq handler completion as a quiescent state. That will likely
help with the route cache overflow problem atleast.


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