From owner-freebsd-arch Tue Dec 18 13:58: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id C4D6637B41D for ; Tue, 18 Dec 2001 13:57:51 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 5346F81E0C; Tue, 18 Dec 2001 15:57:46 -0600 (CST) Date: Tue, 18 Dec 2001 15:57:46 -0600 From: Alfred Perlstein To: Luigi Rizzo Cc: Jonathan Lemon , Julian Elischer , Bruce Evans , arch@FreeBSD.ORG Subject: Re: swi_net Message-ID: <20011218155746.K59831@elvis.mu.org> References: <20011218104750.M377@prism.flugsvamp.com> <20011218125816.N377@prism.flugsvamp.com> <20011218135407.B89299@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011218135407.B89299@iguana.aciri.org>; from rizzo@aciri.org on Tue, Dec 18, 2001 at 01:54:07PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Luigi Rizzo [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