From owner-freebsd-net Tue Jul 3 2: 1:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 1F44337B403; Tue, 3 Jul 2001 02:01:07 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id KAA43664; Tue, 3 Jul 2001 10:55:42 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200107030855.KAA43664@info.iet.unipi.it> Subject: Re: fastforwarding? In-Reply-To: <3B4188F8.5040202@xelerated.com> from Anders Lowinger at "Jul 3, 2001 10:57:28 am" To: Anders Lowinger Date: Tue, 3 Jul 2001 10:55:42 +0200 (CEST) Cc: Jeffrey Hsu , Bakul Shah , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Another way to do it is to switch/route multiple packets > per interrupt. This is a solution a large router vendor as long as you have hardware support for it... The problem is that most devices give you an interrupt when you get the first packet. If your CPU is fast, you are done before the next interrupt comes in from the same interface, and in the meantime you have wasted a lot of time. Some versions of the 21143 have a "interrupt mitigation" register which acts more or less as the VMIN/VTIME termios fields. But the 21143 is hard to find these days, and it is the only one i know with this feature. So in the end you need to resort to some form of polling (as below). cheers luigi > does... > > -Anders > > > one of them is the (relatively high) interrupt overhead, > > as reported by many. There is a good description of the problem > > in the Click's paper at http://www.pdos.lcs.mit.edu/click/ and > > in the Mogul's paper referenced in there. > > > > In line with what is suggested above, reducing this overhead requires > > a solution that involves some form of polling. This gives you > > a lot of improvement in performance, maybe by a factor of 3 or so. > > > > The approach we are trying is based on some very simple modifications > > to the interrupt dispatcher. Basically the idea is to run with > > e.g. HZ=2000 or so, and disable interrupts on a line for the rest > > of a tick after you get more than X interrupts per tick (with small > > X). > > > > The system remains decently responsive, because you are re-enabling > > ints at the next clock tick (in 500us or less), or when you enter > > the idle loop; and when you happen to call ether_output() you have > > a chance to poll the device. > > > > The advantage of this approach is that you don't have to implement > > a real polling system (which can become expensive when the number > > of cards in a box becomes large), and that modifications are > > relatively small and, especially, device-independent. Hopefully > > we will be able to post them soon, after a bit more experiments. > > > > After this change, using FASTFORWARDING seems to save > > another 20-30% on the per-packet processing time. > > > > cheers > > luigi > > -----------------------------------+------------------------------------- > > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > > Mobile +39-347-0373137 > > -----------------------------------+------------------------------------- > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message