Don't forget DragonflyBSD version of PF.
They look an old version of OpenBSD PF and updated it to be multithreaded.
I could be mistaken, but I believe both FreeBSD PF & OpenBSD PF are still single threaded.
They look an old version of OpenBSD PF and updated it to be multithreaded.
I could be mistaken, but I believe both FreeBSD PF & OpenBSD PF are still single threaded.
FWIW the threading in the network stack is one of the original major divergences between Open/FreeBSD PF. The way FreeBSD's PF works is within the context of FreeBSD's threaded network stack. FreeBSD PF is not "single threaded" in the way it used to mean.
I would really like to have the modern PF syntax/structure from OpenBSD in FreeBSD though. The unified rdr/nat/pass/block mechanism in OpenBSD is so much cleaner and nicer to work with.
To elaborate for people who don't know the history: Disagreement about how multithreading should work are why Matt got booted from the FreeBSD project and started DragonFly.
Conflicting personalities makes resolving technical disagreements so much harder.
5.x was a poor vintage because making the kernel SMP was hard, and social issues became problematic because SMP was hard, but Matt's departure was neither the result or cause of FreeBSD 5.x having issues.
The FreeBSD model or DragonflyBSD approach?
First, adding locking is fundamentally easier to get right than rewriting everything into a message-passing model. It took ~5 years to get SMP right in FreeBSD (from when 4.0 was released to when 6.0 was released) but it would have taken double that to get things equally stable and performant with the more intrusive redesign Matt wanted to go with.
Second, pretty much everyone else went with the same locking approach in the end -- which has resulted in CPUs being optimized for that. Lock latencies dropped dramatically with microarchitectural changes between ~2005 and ~2015.
As a theoretical concept, I love the idea behind Dragonfly, but it simply wasn't practical in the real world.
[1] https://man.freebsd.org/cgi/man.cgi?query=pf&apropos=0&sekti...
I'm not an OpenBSD user but it sounds like this changed recently in OpenBSD-land as well, because the "Will multiple processors help?" FAQ entry disappeared some time between January and March 2023: https://web.archive.org/web/20230112170731/https://www.openb...
The number of queues will vary according to the specific NIC chip.
Multiqueue NICs do great work on networking loads when you have 1 core per NIC queue; and you can eliminate or at least reduce cross-core communication for most of the work.
It's not complex firewalling, but I did some HAProxy stuff in tcp mode, and the throughput available when running without queue alignment was miniscule compared to the throughput available when properly aligned. Firewalling has the benefit that queue alignment should happen automagically, because of where it runs. If you're doing a lot of processing in userspace, it makes a lot less of a difference, but on a very lightweight application, there was no point in using more cores than nic queues, because cross-core communication was too slow.