With 7.9, shaping (read: bandwidth rate limiting) no longer tops out at 4 Gbps. PF could always process/transfer beyond 4 Gbps, presuming you had fast enough hardware to handle such bandwidth. The discussed limit was specific only to queues, when using such to shape traffic.
If you're asking about OpenBSD/PF's general network performance, it is finally performing acceptably since a couple of years back. You can easily saturate a 2.5 GbE interface with low-end hardware.
In the days when even cheap consumer hardware ships with 2.5G ports, this number seems weirdly low. Does this mean that basically nobody is currently using OpenBSD in the datacentre or anywhere that might be expecting to handle 10G or higher per port, or is it just filtering that's an issue?
I'm not surprised that the issue exists as even 10 years ago these speeds were uncommon outside of the datacentre, I'm just surprised that nobody has felt a pressing enough need to fix this earlier in the previous few years.
A lot of the time once you get into multi-gig+ territory the answer isn't "make the kernel faster," it's "stop doing it in the kernel."
You end up pushing the hot path out to userland where you can actually scale across cores (DPDK/netmap/XDP style approaches), batch packets, and then DMA straight to and from the NIC. The kernel becomes more of a control plane than the data plane.
PF/ALTQ is very much in the traditional in-kernel, per-packet model, so it hits those limits sooner.
Isnt OpenBSD mainly used for security testing or do I have it wrong? Would be surprised if it was used in production datacenter networking hardware at all. Seems like most people would use one of the proprietary implementations (which likely would include specific written drivers for that hardware) or something like FreeBSD
PF itself is not tailored towards ISPs and/or big orgs. IPFW (FreeBSD) is more powerful and flexible.
OpenBSD shines as a secure all-in-one router SOHO solution. And it’s great because you get all the software you need in the base system. PF is intuitive and easy to work with, even for non network gurus.
OpenBSD was a great OS back in the late 90s and even early 2000s. In some cases it was competing neck to neck with Linux.
Since then, well, Linux grew a lot and OpenBSD not so much. There are multiple causes for this, I will go only through a few: Linux has more support from the big companies; the huge difference in userbase numbers; Linux is more welcoming to new users. And the difference is only growing.
There is no reason to use OpenBSD (aside "we have OpenBSD nerds in staff" or I guess "we don't want to GPL our changes"), we had it ages ago (for the first of mentioned reasons) but even they dumped it once new server hardware wasn't supported.
I would love to use openbsd. I really wanna give it a try but the filesystem choices seem kinda meh. Are there any modern filesystems with good nvme and FDE support for openbsd.
25 comments
[ 3.8 ms ] story [ 49.4 ms ] thread"When we set the upper limit of PC-DOS at 640K, we thought nobody would ever need that much memory." - Bill Gates
If you're asking about OpenBSD/PF's general network performance, it is finally performing acceptably since a couple of years back. You can easily saturate a 2.5 GbE interface with low-end hardware.
I'm not surprised that the issue exists as even 10 years ago these speeds were uncommon outside of the datacentre, I'm just surprised that nobody has felt a pressing enough need to fix this earlier in the previous few years.
You end up pushing the hot path out to userland where you can actually scale across cores (DPDK/netmap/XDP style approaches), batch packets, and then DMA straight to and from the NIC. The kernel becomes more of a control plane than the data plane.
PF/ALTQ is very much in the traditional in-kernel, per-packet model, so it hits those limits sooner.
OpenBSD shines as a secure all-in-one router SOHO solution. And it’s great because you get all the software you need in the base system. PF is intuitive and easy to work with, even for non network gurus.