From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 21:02:46 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 38EE516A400 for ; Fri, 30 Mar 2007 21:02:46 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (tokyo01.jp.mail.your.org [204.9.54.5]) by mx1.freebsd.org (Postfix) with ESMTP id 0A28C13C48C for ; Fri, 30 Mar 2007 21:02:45 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail.your.org (server3-a.your.org [64.202.112.67]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id E2F2B2AD56A6; Fri, 30 Mar 2007 21:02:44 +0000 (UTC) Received: from [69.31.99.11] (pool011.dhcp.your.org [69.31.99.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTP id 2D703A0A44E; Fri, 30 Mar 2007 21:02:43 +0000 (UTC) In-Reply-To: <460D75CE.70804@elischer.org> References: <460D75CE.70804@elischer.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98FE1AAF-DF19-43A8-A5B6-010C852AF489@dragondata.com> Content-Transfer-Encoding: 7bit From: Kevin Day Date: Fri, 30 Mar 2007 16:02:43 -0500 To: Julian Elischer X-Mailer: Apple Mail (2.752.3) Cc: FreeBSD Net , ipfw@freebsd.org Subject: Re: IPFW update frequency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 21:02:46 -0000 On Mar 30, 2007, at 3:40 PM, Julian Elischer wrote: > I have been looking at the IPFW code recently, especially with > respect to locking. > There are some things that could be done to improve IPFW's > behaviour when processing packets, but some of these take a > toll (there is always a toll) on the 'updating' side of things. > > For example. I can make IPFW lock-free during processing of packets > (i.e. not holding any locks while traversing the > list) which would solve problems we have with lock-order reversals > when it needs to look at the socket layer (which needs socket layer > locks). Unfortunatly this would make it a lot more expensive > in the case where new rules are being added to the list. possibly a > LOT > more expensive. Now, this would only matter if one was adding (or > deleting) > hundreds of rules per second to the firewall, but as I've discovered, > there's always SOMEONE that is doing the very thing you imagine that > no-one would ever do. > > In my imagination, most of the people who did this sort of thing don't > need to do it any more as tables obviate the need for that sort of > thing. > > Is there anyone out there who is adding hundreds (or even dozens) > of rules > per second on a continuous basis, or who wants rule changing to > be a really efficient operation? > (does it matter to you if it takes a few milliSecs to add a rule?) > > Julian Would this apply to "dynamic rules", using the keep-state keyword? That'd be a killer for us. If not, the only problem I'd have is that my ipfw startup script adds about 20,000 rules on a reboot. 20,000 rules multiplied by any significant amount of time would be bad, just from a reboot-recovery- time angle. But, if it improved overall performance, I probably wouldn't mind too much. :)