From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 17:08:47 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 798F516A404; Sat, 31 Mar 2007 17:08:47 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 62AB213C484; Sat, 31 Mar 2007 17:08:47 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l2VH8jkq000515; Sat, 31 Mar 2007 09:08:45 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l2VH8jKH000514; Sat, 31 Mar 2007 10:08:45 -0700 (PDT) (envelope-from rizzo) Date: Sat, 31 Mar 2007 10:08:45 -0700 From: Luigi Rizzo To: Max Laier Message-ID: <20070331100845.A307@xorpc.icir.org> References: <460D75CE.70804@elischer.org> <460E19EE.3020700@freebsd.org> <20070331022741.A94927@xorpc.icir.org> <200703311247.19940.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200703311247.19940.max@love2party.net>; from max@love2party.net on Sat, Mar 31, 2007 at 11:47:12AM +0100 Cc: freebsd-ipfw@freebsd.org, Andre Oppermann , Julian Elischer , FreeBSD Net 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: Sat, 31 Mar 2007 17:08:47 -0000 On Sat, Mar 31, 2007 at 11:47:12AM +0100, Max Laier wrote: > On Saturday 31 March 2007 11:27, Luigi Rizzo wrote: ... > See above, ipfw is working in parallel already. In addition to that, > using a ref-count would be worse! Instead of two atomic operations you'd > then have to pay for four: lock ref unlock work lock unref unlock All of > which can contentend each other. This will most likely cause more not sure what you have in mind, but the ref() and unref() are already atomic ops. > serialization than we currently have. Again, please don't rush any > hacks! relax, nobody is rushing, we are in discussion mode! cheers luigi