From owner-freebsd-net Tue Jul 3 1:53:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by hub.freebsd.org (Postfix) with ESMTP id A100737B401; Tue, 3 Jul 2001 01:53:43 -0700 (PDT) (envelope-from anders.lowinger@xelerated.com) Received: from xelerated.com (10.16.5.13 [10.16.5.13]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 31DSBYA9; Tue, 3 Jul 2001 10:53:35 +0200 Message-ID: <3B4188F8.5040202@xelerated.com> Date: Tue, 03 Jul 2001 10:57:28 +0200 From: Anders Lowinger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010628 X-Accept-Language: en-us MIME-Version: 1.0 To: Luigi Rizzo Cc: Jeffrey Hsu , Bakul Shah , freebsd-net@FreeBSD.ORG Subject: Re: fastforwarding? References: <200107022109.XAA38398@info.iet.unipi.it> Content-Type: text/plain; charset=us-ascii; format=flowed 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 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