On Jun 18, 2012, at 11:31 AM, Ryan McBride wrote: > 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).
Okay, I've seen practical real world applications with a single-threaded packet capture going into multiple queues for any number of parallel threads. The beauty is going lockless on those multiple queues if you can make sure the same connections always go to the same thread. This, however, is only interesting if you need to go heavy on throughput or processing, namely DPI and friends. It's fairly straight forward from pf's perspective, but I don't know if pfsync may grow more challenging in the process. Hmm, that SMP-safe network stack sounds interesting, too, but IMO this won't help pf as much as the multi-threading. The two would play together for even more scalability, though. Also, I remember having headaches from trying to bounce packets to their designated CPU (soft interrupt context) under Linux to make the distribution queues lockless themselves. SMP-infused network stacks alone won't cut it, if you are going for anything more than raw IP forwarding throughput. Franco
