[CFT] SMP-friendly pf

[Gleb Smirnoff]

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.