From owner-freebsd-arch Tue Dec 18 13:54:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 4973937B417 for ; Tue, 18 Dec 2001 13:54:15 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBILs7V89423; Tue, 18 Dec 2001 13:54:07 -0800 (PST) (envelope-from rizzo) Date: Tue, 18 Dec 2001 13:54:07 -0800 From: Luigi Rizzo To: Jonathan Lemon Cc: Julian Elischer , Bruce Evans , arch@FreeBSD.ORG Subject: Re: swi_net Message-ID: <20011218135407.B89299@iguana.aciri.org> References: <20011218104750.M377@prism.flugsvamp.com> <20011218125816.N377@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011218125816.N377@prism.flugsvamp.com> User-Agent: Mutt/1.3.23i 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 > 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). cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message