From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 30 20:53:43 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5BA9916A408 for ; Fri, 30 Mar 2007 20:53:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outZ.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 4AAD013C487 for ; Fri, 30 Mar 2007 20:53:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 30 Mar 2007 13:11:33 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id B1FF0125C26; Fri, 30 Mar 2007 13:40:47 -0700 (PDT) Message-ID: <460D75CE.70804@elischer.org> Date: Fri, 30 Mar 2007 13:40:46 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: ipfw@freebsd.org, FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: IPFW update frequency X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 20:53:43 -0000 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