From owner-freebsd-pf@FreeBSD.ORG Thu Jun 14 10:01:13 2012 Return-Path: Delivered-To: pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B41CB1065673 for ; Thu, 14 Jun 2012 10:01:13 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 25B1C8FC0A for ; Thu, 14 Jun 2012 10:01:12 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q5EA1AMQ071971; Thu, 14 Jun 2012 14:01:11 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q5EA1ANo071970; Thu, 14 Jun 2012 14:01:10 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 14 Jun 2012 14:01:10 +0400 From: Gleb Smirnoff To: Chris Buechler Message-ID: <20120614100110.GI28613@FreeBSD.org> References: <20120608061737.GA28197@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: pf@FreeBSD.org Subject: Re: [CFT] SMP-friendly pf X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 10:01:13 -0000 On Sat, Jun 09, 2012 at 03:14:42AM -0400, Chris Buechler wrote: C> > šAs you already probably know, or some may be don't yet know, the pf(4) C> > subsystem in FreeBSD is currently working under a single mutex. This mutex C> > is acquired right at the beginning of any packet processing, and is dropped C> > at the end. While one thread is in pf(4) all other threads are blocked on C> > that mutex. C> > C> > šMeanwhile modern computers are getting more and more cores, and modern C> > network cards getting more MSI interrupts, each serviced by a separate kernel C> > thread in FreeBSD. So the single pf lock, which I call "the pf Giant" :), is C> > getting a point of hard contention. C> > C> > šThree and a half months ago I've started on a project "SMP-friendly pf", C> > which recently have entered alpha stage. As you see from the subject of this C> > mail, this is call for testing. C> > C> > šWilling to test? C> C> Absolutely. Are there any particular areas specifically that you would C> like some testing focus on? Obviously testing everything is needed to C> ensure nothing is broken, and I'm definitely interested in doing some C> performance comparisons on SMP and non-SMP hardware. But not sure what C> areas you've already focused on, and what areas you feel need more C> testing focus than others, if any. I'm currently running it with quite simple rulesets with couple of rdr rules and that's all. - Testing with more complex rulesets is interesting. - Situations with rapidly changing rulesets or appearing and disappearing interfaces, or table entries are potentially dangerous once pf is no longer under one lock. - routing rules, uid/gid rules Performance increase could be probably noticed only at large state tables, probably > 100k, on box with several cores and several NICs, or with a NIC that runs multiple threads (igb(4) for example). -- Totus tuus, Glebius.