From owner-freebsd-current Fri Jan 7 9:49:49 2000 Delivered-To: freebsd-current@freebsd.org Received: from modemcable126.102-200-24.mtl.mc.videotron.net (modemcable156.106-200-24.mtl.mc.videotron.net [24.200.106.156]) by hub.freebsd.org (Postfix) with SMTP id C21B514F81 for ; Fri, 7 Jan 2000 09:49:43 -0800 (PST) (envelope-from patrick@mindstep.com) Received: (qmail 51889 invoked from network); 7 Jan 2000 17:49:37 -0000 Received: from dhcp-mtl-200.local.mindstep.com (HELO patrak) (192.168.10.200) by jacuzzi.local.mindstep.com with SMTP; 7 Jan 2000 17:49:37 -0000 Message-ID: <003301bf5937$90b0c340$c80aa8c0@local.mindstep.com> From: "Patrick Bihan-Faou" To: "Luigi Rizzo" Cc: References: <200001070922.KAA03892@info.iet.unipi.it> Subject: Re: ipfw optimizations Date: Fri, 7 Jan 2000 12:49:37 -0500 Organization: MindStep Corporation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Luigi, > i am looking at (minor) optimizations of the ipfw code in order to reduce > the running time in the common cases. > > I have a few ideas (mostly along the lines of optimizing for the > most commonly-used rules). An obvious candidate is the 'match all' > rule (all from any to any), but can people suggest other common > usage of rules in ipfw ? One of the things I would do to optimize ipfw is: - instead of keeping one list with all the rules, split the list (the internal one) by interface and by direction (one list for ed1 incoming, one list for ed1 outgoing, etc.). - then eventually you could be doing the same thing by IP protocol number, but it might not be worth it (with regard to the amount of work required). I think that it is a better way to optimize ipfw than optimize the "match all" rule, since in any security conscious this is likely to be a deny rule, and who cares if it takes a little longer to deny a packet ? My goal usually is to accept legitimate packets as early as possible, reject really obvious stuff also fairly early and then handle the less common stuff. At last there is my match all deny rule, but it does not get exercised that often. One advantage of having a compiled ruleset for each interface would speed up quite a bit the processing by not going over rules that are not applicable. I looked once at doing that on the 3.x-STABLE ipfw, and even if it did not seem to be *too* complicated to do, I did not have the time to go further. Any thoughts ? Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message