Testaufruf: "smp-pf" Alpha

[Yamagi]

Hallo,
OpenBSDs "pf" Paketfilter ist nun bereits seit vielen Jahren in FreeBSD verfügbar und inzwischen wohl der beliebteste der drei Paketfilter. Grund dafür ist vor allem der eingängige Syntax. Nur war, bzw. ist, eines der großen Probleme von pf unter FreeBSD seine fehlende Unterstützung für Multiprozessorsysteme. Dies macht pf zu einem Flaschenhals im sonst gut skalierenden Kernel. Zum Filter sehr großer Paketmengen auf entsprechend schnellen Links (10Gbit/s oder mehr) oder vielen Links parallel ist pf daher nur wenig geeignet. Es gibt bereits seit längerer Zeit Bestrebungen daran etwas zu ändern, dies als "SMP-friendly pf" oder kurz "smp-pf" bekannte Projekt hat nun einen Stand erreicht, der das Testen durch dritte Personen ermöglicht. "smp-pf" ist de facto ein Fork von pf in OpenBSD 4.5, der einen großen Teil des Codes ändert, im Interface aber wohl kompatibel bleibt. Wer testen möchte, findet weitere Informationen im Testaufruf:

  Hello, networkers!

  [net@ in Cc, but further discussion should go on pf@]

  As you already probably know, or some may be don't yet know, the pf(4)
subsystem in FreeBSD is currently working under a single mutex. This mutex
is acquired right at the beginning of any packet processing, and is dropped
at the end. While one thread is in pf(4) all other threads are blocked on
that mutex.

  Meanwhile modern computers are getting more and more cores, and modern
network cards getting more MSI interrupts, each serviced by a separate kernel
thread in FreeBSD. So the single pf lock, which I call "the pf Giant" :), is
getting a point of hard contention.

  Three and a half months ago I've started on a project "SMP-friendly pf",
which recently have entered alpha stage. As you see from the subject of this
mail, this is call for testing.


  Willing to test?

  The code lives in projects/pf/head branch in the SVN, and can be checked
out with:

  svn checkout http://svn.freebsd.org/base/projects/pf/head pflock

, where argument "pflock" is just directory name for checked out sources.
  Then you need to build world and kernel from that branch and install them.
The branch projects/pf/head gets head merged to it quite often, so if you
run head world with a revision equal (or at least close) to last merge, then
you don't need to install world, however rebuilding pfctl and snmp_pf from
that branch is necessary.
  If you are about to run this alpha pf on any important box, then you
definitely need to establish safety measures: have a second box running
stable/9 or head as carp(4) backup, ready to kick in, in case if new pf
panics. pfsync(4) connection should also be established between new and
backup boxes. pfsync(4) in the new code is wire compatible with stable/9
or head.
  I'm already running it on routers with 100k - 200k state entries, and
forwarding 20k - 40k pps. If you are brave, you should try, too :) Good
luck and report any problems to me!


  Interested in details?

  From the very beginning of the project it was clear, that code is going
to diverge significantly from original OpenBSD code. OpenBSD has always
developed pf without taking into account that code can ever get
multithreaded, thus quite a lot needed to be changed. Thus, I've started
with removing the "#ifdef __FreeBSD__" from the code, and later I didn't
hesitate even a fraction of second if I wanted to toss some code. The pros
is that now code is much more readable and understandible then in head,
the cons is that diff between us and OpenBSD is huge, although amount
of shared code is huge, too. So, later on only manual merging of features
from OpenBSD is possible and bulk imports of entire pf into FreeBSD are
no longer possible.

  The locking scheme is the following:
- There is an rwlock(9) that protects rules and all kind of data that isn't
  modified by forwarding threads. Forwarding threads reader lock it, ioctl()
  and other reconfiguring events write lock it.
- The states and key states storage had moved from RB-trees to hashes, with
  separate mutexes per hash slot. This should give us decent parallelism
  when forwarding packets.
- Source nodes storage moved to hash with per-slot locking.
- pfsync(4) got separate mutex.
- fragment reassembly got separate mutex.

  Apart from the above key changes, many other optimisations and fixes done.
The entire diff is 22k lines large. You can view the projects history here:

http://svnweb.freebsd.org/base/projects/pf/head/?view=log

(the beginning is on page 2 now, at r232042) I had tried to make informative
commit messages.

-- 
Totus tuus, Glebius.

[kai_001]

Ein Traum ... Danke für die Info!

Grüße,
Kai

[Crest]

Mal wieder ein Projekt für dessen Ziel man sich gerne ein paar Kernelpanics an sieht.

[Kamikaze]

Cool. Jetzt brauche ich nur noch den Backbone mit 24 10GBit NICs, Quad-Quadcore und den nötigen Traffic um Das sinnvoll zu testen.

[Bummibaer]

Hoi,
könnt mer de Test ned oifach de Junipbär uf de Rüssel nageln ?

Der vertickt des ja später eh wieder in sei Software und die nötige Ausrüstung zum das sinnvoll prüfen steht in dem Devlab da ja eh rum. Eventuell sollt dem das mal wer antragen.

Gruß Bummibär

[oenone]

10GBit/s sind für OpenBSD nicht wirklich ein Problem...

[bofh_hannibal]

10GBit/s sind für OpenBSD nicht wirklich ein Problem...

@oenone:
Naja, routing alleine JA, aber routing + fw mit pf glaub ich kaum das da 10Gbit noch drin sind. Ein "echter" SMP Kernel der dann auch SMP-PF kann, das wäre genial.
Heutige Firewalls haben nun mal mehrere 10Gbit Ports und die wollen performant bedient werden. Ohne das die CPU bei 100% ist oder nur ein Core alles macht.
Und der Bus wird bald auch nicht mehr der Flaschenhals sein als es jetzt noch der fall ist. Dann liegt es am OS den Datenstrom effizient zu handhaben !

Auch eine Virtualisierung der PF unter OpenBSD wäre mal ein Projekt wert.
Dann könnte man mit einer Maschine hunderte Kunden Firewalls aufbauen anstatt jeden Kunden eine Maschine zu geben (nicht geclustert).


Mfg,

bofh

[mark05]

Zitat von bofh_hannibal

@oenone:
Naja, routing alleine JA, aber routing + fw mit pf glaub ich kaum das da 10Gbit noch drin sind. Ein "echter" SMP Kernel der dann auch SMP-PF kann, das wäre genial.
Heutige Firewalls haben nun mal mehrere 10Gbit Ports und die wollen performant bedient werden. Ohne das die CPU bei 100% ist oder nur ein Core alles macht.
Und der Bus wird bald auch nicht mehr der Flaschenhals sein als es jetzt noch der fall ist. Dann liegt es am OS den Datenstrom effizient zu handhaben !

Auch eine Virtualisierung der PF unter OpenBSD wäre mal ein Projekt wert.
Dann könnte man mit einer Maschine hunderte Kunden Firewalls aufbauen anstatt jeden Kunden eine Maschine zu geben (nicht geclustert).


Mfg,

bofh

moin

also virtualisierung und pf

ja ne is klar .

1 oder mehre 10 gbit interfaces ist nicht wirklich das problem.

holger

[Bummibaer]

Zitat von bofh_hannibal

@oenone:
...Auch eine Virtualisierung der PF unter OpenBSD wäre mal ein Projekt wert.
Dann könnte man mit einer Maschine hunderte Kunden Firewalls aufbauen anstatt jeden Kunden eine Maschine zu geben (nicht geclustert)....

Ähm Jungs, hört Ihr die Einschläge eigentlich noch ?

Absolut keiner möchte eine Kiste wo so viele Firewalls von unterschiedlichen Kunden parallel virtualisiert darauf springen. Das ist so ziemlich das Letzte was jemand möchte.

Gruß Bummibär

[Crest]

Bummibaer: Doch die Marketingabteilung.

[waki87]

Öhm, gibt es doch, Stichwort »rdomains«. Siehe auch diesen schönen Vortrag von claudio@: http://www.youtube.com/watch?v=NfyyBI7JHQI

[h^2]

Irgendwie wird das Thema langweilig. Ein paar Luet behaupten die ganze Zeit 10Gbit (oder sogar multiple 10 Gbits ports) seien problemlos mit OpenBSD PF zu filtern, andere behaupten, nein auf keinen Fall.
Wir sind doch kein Religionsverein, sondern Empiristen.

Kann irgendjemand bitte mal Zahlen liefern?

[Kamikaze]

Gegen Spende eines Backbones mit 24 10-Gbit Ports und 8 oder 16 Kernen mache ich gerne eine Messserie mit verschiedenen Routing und Balancing Scenarien.

[Crest]

Wer nicht?

[mark05]

ich , keine zeit