netdev
[Top] [All Lists]

Re: [announce] [patch] limiting IRQ load, irq-rewrite-2.4.11-B5

To: Benjamin LaHaise <bcrl@xxxxxxxxxx>, Alex Bligh - linux-kernel <linux-kernel@xxxxxxxxxxx>
Subject: Re: [announce] [patch] limiting IRQ load, irq-rewrite-2.4.11-B5
From: Alex Bligh - linux-kernel <linux-kernel@xxxxxxxxxxx>
Date: Fri, 05 Oct 2001 00:20:34 +0100
Cc: mingo@xxxxxxx, jamal <hadi@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>, Robert Olsson <Robert.Olsson@xxxxxxxxxxx>, netdev@xxxxxxxxxxx, Linus Torvalds <torvalds@xxxxxxxxxxxxx>, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>, Simon Kirby <sim@xxxxxxxxxxxxx>, Alex Bligh - linux-kernel <linux-kernel@xxxxxxxxxxx>
In-reply-to: <20011004174945.B18528@xxxxxxxxxx>
References: <20011004174945.B18528@xxxxxxxxxx>
Reply-to: Alex Bligh - linux-kernel <linux-kernel@xxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx


--On Thursday, 04 October, 2001 5:49 PM -0400 Benjamin LaHaise <bcrl@xxxxxxxxxx> wrote:

In at least one environment known to me (router), I'd rather it
kept accepting packets, and f/w'ing them, and didn't switch VTs etc.
By dropping down performance, you've made the DoS attack even
more successful than it would otherwise have been (the kiddie
looks at effect on the host at the end).

Then bug the driver author of your ethernet cards or turn the hammer off.
 You're the sysadmin, you know that your system is unusual.  Deal with it.

The hammer has an average age of 13yrs and is difficult to turn off,
unfortunately.

Rather than bugging the author of the driver card, we've actually
been trying to fix it, down to rewriting the firmware. So for
this purpose I/we am/are the driver maintainer thanks. However,
there are limitations like bus speed which mean that in practice
if we receive a large enough number of small packets each second,
the box will saturate.

My point was merely that some applications (and using a linux
box as a router is not that 'unusual') want to deprioritize
different things under resource starvation. Changing the default,
in an unconfigurable way, isn't a great idea. Sure dealing
with external resource exhaustions for hosts is indeed a good
idea. I was just suggesting that it wasn't always what you
wanted to do.

Not sure this required jumping down my throat.

--
Alex Bligh

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