From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 23:50:50 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 5D50916A409 for ; Fri, 30 Mar 2007 23:50:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outX.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id 4B60013C4B0 for ; Fri, 30 Mar 2007 23:50:50 +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 16:21:34 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 2E367125D68; Fri, 30 Mar 2007 16:50:49 -0700 (PDT) Message-ID: <460DA258.2030402@elischer.org> Date: Fri, 30 Mar 2007 16:50:48 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Luigi Rizzo References: <460D75CE.70804@elischer.org> <20070330145938.A88154@xorpc.icir.org> In-Reply-To: <20070330145938.A88154@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 23:50:50 -0000 Luigi Rizzo wrote: > On Fri, Mar 30, 2007 at 01:40:46PM -0700, 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. > > certainly ipfw was not designed with SMP in mind. > If you can tell us what is your plan to make the list lock free > (which one, the static or dynamic ones ?) maybe we can comment more. > > E.g. one option could be the usual trick of adding refcounts to > the individual rules, and then using an array of pointers to them. > While processing you grab a refcount to the array, and release it once > done with the packet. If there is an addition or removal, you duplicate > the array (which may be expensive for the large 20k rules mentioned), > manipulate the copy and then atomically swap the pointers to the head. This is pretty close.. I know I've mentioned this to people several times over the last year or so. the trick is to try do it in a way that the average packet doesn't need to do any locks to get in and the updater does more work. if you are willing to acquire a lock on both starting and ending the run through the firewall it is easy. (I already have code to do that..) (see http://www.freebsd.org/~julian/atomic_replace.c (untested but probably close.) doing it without requiring that each packet get those locks however is a whole new level of problem. > > This might even work for dynamic rules as the lists (the content of > each hash bucket) are typically short. yep > > cheers > luigi