3 ms·

If they're concerned about performance, yeah. OpenBSD doesn't do the basics that you need to get the most out of your SMP hardware; there's no way to set cpu af

by toast0 1y ago

If they're concerned about performance, yeah. OpenBSD doesn't do the basics that you need to get the most out of your SMP hardware; there's no way to set cpu affinity at least from userland, and it's clear that this sort of work is not a priority for OpenBSD; it's not easy work, but FreeBSD has done it. Beyond CPU affinity, you also need your network structures setup to reduce lock contention, things like fine grained locks, hashed subtables and/or "lockless" tables, configuring the NICs as close as possible to one queue per core and keeping flows on the same queue which is pinned to a single core so that the per flow locks never contend and don't bounce between cores. Ubuntu/Linux do have reasonable performance, but I think they prefer PF firewalls, so that makes Linux a non-option for firewalls. Personally, I don't really care for PF, but it offers pfsync, which I do care for, so I use it and ipfw... but I need to check in, I think FreeBSD PF may have added the hooks I use ipfw for (bandwidth limits/shaping/queue discipline).

csmpltn 1y ago
> "there's no way to set cpu affinity at least from userland" How is that even possible. What's the excuse? On Windows, setting process affinity has been around since the Windows NT days.
- doubled112 1y ago
  It's the OS's job to manage resources.
  - Twirrim 1y ago
    The OS doesn't always know everything about workloads to be able to make the right decisions.
- toast0 1y ago
  I was pretty sure I had seen a mailing list post from Theo about it, but I can't find it now. The only relevant thread I can find is this one [1], which pretty much just says "we don't do it for userland"; but does say it is available inside the kernel, and I have seen some mentions in recent release notes for OpenBSD of binding PF things by toeplitz hash, which indicates the right progression for that ... but it's still hard to get max performance from a simple network daemon without binding the userland threads to same core that the kernel processes the flow with. Once your daemon starts doing substantial work, binding cpus isn't as important, but if it's something like an authoritative DNS server or HAProxy with plain sockets, the performance benefit from eliminating cross-core communication can be tremendous. [1] https://marc.info/?l=openbsd-misc&m=152507006602422&w=2 https://marc.info/?l=openbsd-misc&m=152507006602422&w=2
- thesuitonym 1y ago
  The gp already answered you, "this sort of work is not a priority for OpenBSD." OpenBSD is a small, niche operating system, and it really only gets support for something if it solves a problem for someone who writes OpenBSD code. In a way, this is nice, because you never get half-assed features that kinda-sorta work sometimes, maybe. Everything either works exactly as you'd expect, or it's just not there. I love OpenBSD, but there are some tasks it's just not suited for, and that's fine, too.
seanw444 1y ago
It's not necessarily that OpenBSD can't implement the basics, it's that they don't want to. A lot of the high-performance features introduce potential security vulnerabilities. Their main focus is security and correctness. Not speed.
- Terr_ 1y ago
  > A lot of the high-performance features introduce potential security vulnerabilities. I am particularly-reminded of speculative execution optimizations allowing attacks like Spectre and Meltdown in 2017. https://en.wikipedia.org/wiki/Transient_execution_CPU_vulnerability https://en.wikipedia.org/wiki/Transient_execution_CPU_vulner...

by toast0 1y ago

csmpltn 1y ago

> "there's no way to set cpu affinity at least from userland" How is that even possible. What's the excuse? On Windows, setting process affinity has been around since the Windows NT days.

doubled112 1y ago
It's the OS's job to manage resources.
- Twirrim 1y ago
  The OS doesn't always know everything about workloads to be able to make the right decisions.
toast0 1y ago
I was pretty sure I had seen a mailing list post from Theo about it, but I can't find it now. The only relevant thread I can find is this one [1], which pretty much just says "we don't do it for userland"; but does say it is available inside the kernel, and I have seen some mentions in recent release notes for OpenBSD of binding PF things by toeplitz hash, which indicates the right progression for that ... but it's still hard to get max performance from a simple network daemon without binding the userland threads to same core that the kernel processes the flow with. Once your daemon starts doing substantial work, binding cpus isn't as important, but if it's something like an authoritative DNS server or HAProxy with plain sockets, the performance benefit from eliminating cross-core communication can be tremendous. [1] https://marc.info/?l=openbsd-misc&m=152507006602422&w=2 https://marc.info/?l=openbsd-misc&m=152507006602422&w=2
thesuitonym 1y ago
The gp already answered you, "this sort of work is not a priority for OpenBSD." OpenBSD is a small, niche operating system, and it really only gets support for something if it solves a problem for someone who writes OpenBSD code. In a way, this is nice, because you never get half-assed features that kinda-sorta work sometimes, maybe. Everything either works exactly as you'd expect, or it's just not there. I love OpenBSD, but there are some tasks it's just not suited for, and that's fine, too.

seanw444 1y ago

It's not necessarily that OpenBSD can't implement the basics, it's that they don't want to. A lot of the high-performance features introduce potential security vulnerabilities. Their main focus is security and correctness. Not speed.

Terr_ 1y ago
> A lot of the high-performance features introduce potential security vulnerabilities. I am particularly-reminded of speculative execution optimizations allowing attacks like Spectre and Meltdown in 2017. https://en.wikipedia.org/wiki/Transient_execution_CPU_vulnerability https://en.wikipedia.org/wiki/Transient_execution_CPU_vulner...