From owner-freebsd-net Mon Jul 2 14:15: 6 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 0B98E37B405; Mon, 2 Jul 2001 14:15:02 -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 XAA38398; Mon, 2 Jul 2001 23:09:45 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200107022109.XAA38398@info.iet.unipi.it> Subject: Re: fastforwarding? In-Reply-To: <0GFV00LBT5EXRH@mta8.pltn13.pbi.net> from Jeffrey Hsu at "Jul 2, 2001 01:39:54 pm" To: Jeffrey Hsu Date: Mon, 2 Jul 2001 23:09:45 +0200 (CEST) Cc: 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 > > > a stock freebsd system can't do more than 20K ~ 100K pkts/second due to > > many bottlenecks > > I'd be interested in knowing where those bottlenecks were and fixing them. 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