Date: Thu, 14 Jun 2012 14:01:10 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Chris Buechler <cmb@pfsense.org> Cc: pf@FreeBSD.org Subject: Re: [CFT] SMP-friendly pf Message-ID: <20120614100110.GI28613@FreeBSD.org> In-Reply-To: <CAOmxWMV_JVLkOkPGskR1v54rgqYzGNLsOq_J_nT-2HQwF%2Bj6aw@mail.gmail.com> References: <20120608061737.GA28197@glebius.int.ru> <CAOmxWMV_JVLkOkPGskR1v54rgqYzGNLsOq_J_nT-2HQwF%2Bj6aw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120614100110.GI28613>