Date: Tue, 3 Jul 2001 10:55:42 +0200 (CEST) From: Luigi Rizzo <luigi@info.iet.unipi.it> To: Anders Lowinger <anders.lowinger@xelerated.com> Cc: Jeffrey Hsu <hsu@FreeBSD.ORG>, Bakul Shah <bakul@bitblocks.com>, freebsd-net@FreeBSD.ORG Subject: Re: fastforwarding? Message-ID: <200107030855.KAA43664@info.iet.unipi.it> In-Reply-To: <3B4188F8.5040202@xelerated.com> from Anders Lowinger at "Jul 3, 2001 10:57:28 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107030855.KAA43664>