From owner-cvs-src@FreeBSD.ORG Thu Feb 2 17:33:53 2006 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E323A16A420; Thu, 2 Feb 2006 17:33:53 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id B44A043D46; Thu, 2 Feb 2006 17:33:52 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 7573731 for multiple; Thu, 02 Feb 2006 12:34:28 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k12HXoMe003023; Thu, 2 Feb 2006 12:33:50 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Christian S.J. Peron" Date: Thu, 2 Feb 2006 11:29:52 -0500 User-Agent: KMail/1.9.1 References: <200602020313.k123DGFl029834@repoman.freebsd.org> In-Reply-To: <200602020313.k123DGFl029834@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602021129.55084.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1270/Thu Feb 2 07:47:37 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/net pfil.c pfil.h src/sys/netinet ip_fastfwd.c ip_fw2.c ip_input.c ip_output.c src/sys/netinet6 ip6_forward.c ip6_input.c ip6_output.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 17:33:54 -0000 On Wednesday 01 February 2006 22:13, Christian S.J. Peron wrote: > csjp 2006-02-02 03:13:16 UTC > > FreeBSD src repository > > Modified files: > sys/net pfil.c pfil.h > sys/netinet ip_fastfwd.c ip_fw2.c ip_input.c > ip_output.c > sys/netinet6 ip6_forward.c ip6_input.c ip6_output.c > Log: > Somewhat re-factor the read/write locking mechanism associated with the > packet filtering mechanisms to use the new rwlock(9) locking API: > > - Drop the variables stored in the phil_head structure which were > specific to conditions and the home rolled read/write locking mechanism. > - Drop some includes which were used for condition variables > - Drop the inline functions, and convert them to macros. Also, move these > macros into pfil.h > - Move pfil list locking macros intp phil.h as well > - Rename ph_busy_count to ph_nhooks. This variable will represent the > number of IN/OUT hooks registered with the pfil head structure > - Define PFIL_HOOKED macro which evaluates to true if there are any > hooks to be ran by pfil_run_hooks > - In the IP/IP6 stacks, change the ph_busy_count comparison to use the > new PFIL_HOOKED macro. > - Drop optimization in pfil_run_hooks which checks to see if there are > any hooks to be ran, and returns if not. This check is already performed by > the IP stacks when they call: > > if (!PFIL_HOOKED(ph)) > goto skip_hooks; > > - Drop in assertion which makes sure that the number of hooks never drops > below 0 for good measure. This in theory should never happen, and if it > does than there are problems somewhere > - Drop special logic around PFIL_WAITOK because rw_wlock(9) does not > sleep - Drop variables which support home rolled read/write locking > mechanism from the IPFW firewall chain structure. > - Swap out the read/write firewall chain lock internal to use the > rwlock(9) API instead of our home rolled version > - Convert the inlined functions to macros > > Reviewed by: mlaier, andre, glebius > Thanks to: jhb for the new locking API Do the new locks perform better in any benchmarks than the previous version of what you were doing? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org