Date: Tue, 18 Dec 2001 15:57:46 -0600 From: Alfred Perlstein <bright@mu.org> To: Luigi Rizzo <rizzo@aciri.org> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, Julian Elischer <julian@elischer.org>, Bruce Evans <bde@zeta.org.au>, arch@FreeBSD.ORG Subject: Re: swi_net Message-ID: <20011218155746.K59831@elvis.mu.org> In-Reply-To: <20011218135407.B89299@iguana.aciri.org>; from rizzo@aciri.org on Tue, Dec 18, 2001 at 01:54:07PM -0800 References: <20011218104750.M377@prism.flugsvamp.com> <Pine.BSF.4.21.0112181017000.36281-100000@InterJet.elischer.org> <20011218125816.N377@prism.flugsvamp.com> <20011218135407.B89299@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Luigi Rizzo <rizzo@aciri.org> [011218 15:54] wrote:
> > One thing to note is that so far, I haven't seen any benefit of using
> > a direct dispatch over the netisr approach; but then again, it may be
> > that I'm simply not stressing my system enough.
>
> Direct dispatch is typically useful under heavy load, because:
>
> * it reduces the chance of livelock when you have lots of traffic
> coming from an interface (which gets queued without giving the
> netisr a chance to run);
>
> * as a side effect, it also works as a form of interrupt mitigation,
> because you stay longer in the ISR and so you might serve more
> packets on a single interrupt.
>
> As a drawback, if your packet processing time is longer than
> the packet interarrival time (which is sometimes possible under
> attack), you might remain in your ISR forever, literally.
>
> Just as a side note, the polling code deals very well with the above
> problems, and is not subject to the last one.
>
> I have been against deferred processing for a long time, but recently
> have slightly changed my mind because i now see a reason in it (mentioned in
> the previous msg, re. expensive processing), as long as you can reserve
> some amount of CPU to the deferred processing, and you make sure that
> interfaces are served in a fair way (early versions of the polling code had
> this problem, fetching large chunks of packets from the first interface
> and filling up the intermediate queue. The version in current has not,
> because ether_pollmore() among other things makes sure that interfaces
> are served in a round-robin fashion and with short bursts of packets
> before calling the netisr).
It makes sense to switch to direct dispatch when the queue fills as
you'll leave the hardware interrupt blocked and then be able to
process your data.
This doesn't mean that you'll be able to run userland code, but at
least packets will move and not just be dropped from the queue.
--
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
http://www.morons.org/rants/gpl-harmful.php3
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011218155746.K59831>