No, there is no single mutex around PF specifically in OpenBSD, the whole kernel is wrapped in a biglock.
I think if they work out all the nits and dead-ends we may have something to learn from this effort, but I don't see this code coming back to OpenBSD. It's not critical because they can change the state table implementation later - OpenBSD has reorganised this several times with more planned - but we've put quite a bit of effort into removing hash tables in our kernel wherever possible, partly due to their attackability. My personal preference would be to go with a lockless or lock-on-write RB tree for the state table, but without an SMP-safe network stack there's little motivation to work on such things (though it remains somewhere on my todo list). On Mon, Jun 18, 2012 at 10:06:01AM +0200, Franco Fichtner wrote: > On Jun 17, 2012, at 7:53 PM, Ted Unangst wrote: > > > On Sun, Jun 17, 2012 at 11:43, Holger Glaess wrote: > > > >> i dident wont start about smp on openbsd but > >> > >> what about this porject ? > > > > Did you read the part below? I think it's pretty clear this project > > isn't going to have much relevance for OpenBSD. > > > >> 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. > > This sounds like a messy decision. Is this single-mutex stuff in pf true > for OpenBSD as of now or a port quirk of FreeBSD's version? I worked on a > heavily multi-threaded firewall core for a few years and I would be glad > to help pf itself instead of a 4.5-based pf port going SMP, chasing > rainbows and unicorns.
