3 ms·

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 Fr

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. https://man.dragonflybsd.org/?command=pf&section=4 https://man.dragonflybsd.org/?command=pf&section=4

postmodest 3y ago
The only advantage I can see to MT PF would be multiple NICs. And even then they have to be really beefy NICs
- smashed 3y ago
  From what I understand, modern NICs have multiple Rx/tx queues and thus the work of sending and receiving can be assigned to different kernel threads. The number of queues will vary according to the specific NIC chip.
  - toast0 3y ago
    I was going to say something similar. 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.
darkhelmet 3y ago
DragonFly and FreeBSD have radically different ideas on how multithreading should work. (Understatement of the century right there!) 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.
- cperciva 3y ago
  DragonFly and FreeBSD have radically different ideas on how multithreading should work. (Understatement of the century right there!) 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.
  - darkhelmet 3y ago
    It's not that simple. Disagreements are one thing, but the real reason was the conflict and drama that happened when things didn't go his way. The threading approach just happened to be a really good trigger for those conflicts. Conflicting personalities makes resolving technical disagreements so much harder.
    - cperciva 3y ago
      I was being euphemistic. It was a "doesn't play well with others" issue, but it came to the fore with SMP.
      - bch 3y ago
        Playing well obviously important (and I wasn’t involved, have no other insight), but do you know if the poor showing for fbsd 5.x correspond w the disagreements?
        cperciva 3y ago
        FreeBSD 5.x was a very stressful time -- bringing full SMP to the entire kernel was a massive technical challenge, and it didn't help that a lot of the people who were expecting to work on it lost their jobs during the dot com crash. 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.
        3y ago
dmm 3y ago
FreeBSD pf has been multithreaded for a long time. The FreeBSD 11 pf(4) man page from 2013 specifically says so[1]. [1] https://man.freebsd.org/cgi/man.cgi?query=pf&apropos=0&sektion=4&manpath=FreeBSD+11.0-RELEASE&arch=default&format=html#end https://man.freebsd.org/cgi/man.cgi?query=pf&apropos=0&sekti...
- Lammy 3y ago
  "SMP" might be a more useful search term. You're correct on the timeframe — merged into HEAD in 2012 https://lists.freebsd.org/pipermail/freebsd-pf/2012-September/006740.html https://lists.freebsd.org/pipermail/freebsd-pf/2012-Septembe... 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.openbsd.org/faq/pf/perf.html https://web.archive.org/web/20230112170731/https://www.openb...
  - gigatexal 3y ago
    I didn’t know this but it makes sense. Either way for most of the use cases (homelabs on residential internet speeds) either FBSD or OpenBSD’s PF will perform just swimmingly.

postmodest 3y ago

The only advantage I can see to MT PF would be multiple NICs. And even then they have to be really beefy NICs

smashed 3y ago
From what I understand, modern NICs have multiple Rx/tx queues and thus the work of sending and receiving can be assigned to different kernel threads. The number of queues will vary according to the specific NIC chip.
- toast0 3y ago
  I was going to say something similar. 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.

darkhelmet 3y ago

DragonFly and FreeBSD have radically different ideas on how multithreading should work. (Understatement of the century right there!) 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.

cperciva 3y ago
DragonFly and FreeBSD have radically different ideas on how multithreading should work. (Understatement of the century right there!) 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.
- darkhelmet 3y ago
  It's not that simple. Disagreements are one thing, but the real reason was the conflict and drama that happened when things didn't go his way. The threading approach just happened to be a really good trigger for those conflicts. Conflicting personalities makes resolving technical disagreements so much harder.
  - cperciva 3y ago
    I was being euphemistic. It was a "doesn't play well with others" issue, but it came to the fore with SMP.
    - bch 3y ago
      Playing well obviously important (and I wasn’t involved, have no other insight), but do you know if the poor showing for fbsd 5.x correspond w the disagreements?
      - cperciva 3y ago
        FreeBSD 5.x was a very stressful time -- bringing full SMP to the entire kernel was a massive technical challenge, and it didn't help that a lot of the people who were expecting to work on it lost their jobs during the dot com crash. 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.
        3y ago

dmm 3y ago

FreeBSD pf has been multithreaded for a long time. The FreeBSD 11 pf(4) man page from 2013 specifically says so[1]. [1] https://man.freebsd.org/cgi/man.cgi?query=pf&apropos=0&sektion=4&manpath=FreeBSD+11.0-RELEASE&arch=default&format=html#end https://man.freebsd.org/cgi/man.cgi?query=pf&apropos=0&sekti...

Lammy 3y ago
"SMP" might be a more useful search term. You're correct on the timeframe — merged into HEAD in 2012 https://lists.freebsd.org/pipermail/freebsd-pf/2012-September/006740.html https://lists.freebsd.org/pipermail/freebsd-pf/2012-Septembe... 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.openbsd.org/faq/pf/perf.html https://web.archive.org/web/20230112170731/https://www.openb...
- gigatexal 3y ago
  I didn’t know this but it makes sense. Either way for most of the use cases (homelabs on residential internet speeds) either FBSD or OpenBSD’s PF will perform just swimmingly.