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.
Someone 1 days ago [-]
The article is about allowing bandwidth restrictions in bytes/second that are larger than 2³²-1, not about how fast pf can filter packets.
I guess few people with faster ports felt the need to limit bandwidth for a service to something that’s that large.
FTA:
“OpenBSD's PF packet filter has long supported HFSC traffic shaping with the queue rules in pf.conf(5). However, an internal 32-bit limitation in the HFSC service curve structure (struct hfsc_sc) meant that bandwidth values were silently capped at approximately 4.29 Gbps, ” the maximum value of a u_int ".
With 10G, 25G, and 100G network interfaces now commonplace, OpenBSD devs making huge progress unlocking the kernel for SMP, and adding drivers for cards supporting some of these speeds, this limitation started to get in the way. Configuring bandwidth 10G on a queue would silently wrap around, producing incorrect and unpredictable scheduling behaviour.
A new patch widens the bandwidth fields in the kernel's HFSC scheduler from 32-bit to 64-bit integers, removing this bottleneck entirely.”
nine_k 1 days ago [-]
> silently wrap around, producing incorrect and unpredictable
Now I'm more scared to use OpenBSD than I was a minute before.
I strongly prefer software that fails loudly and explicitly.
Someone 2 hours ago [-]
It’s a fairly common issue with C code, so you should be scared about more than OpenBSD. As an example:
a_long = an_int * another_int;
will do the multiplication in integers, then convert the result to long. That can produce surprising results of the multiplication overflows (I think that, technically, that would be undefined behavior, allowing the compiler to do what it wants, but most compilers will generate a multiplication instruction and let the CPU do whatever it does with int overflow (wrap around and trapping are the most popular options)
Also,
an_int = a_long;
is valid, and will do a narrowing conversion. I don’t think compilers are required to warn about that.
kaashif 1 days ago [-]
Yeah, that's pretty appalling.
Regardless of how good the philosophy of something is, if it's as niche and manpower constrained as OpenBSD is then it's going to accumulate problems like this.
muvlon 1 days ago [-]
I actually think this isn't even surprising from OpenBSD philosophically. They still subscribe to the Unix philosophy of old, moreso than FreeBSD and much much more than Linux.
That is, "worse is better" and it's okay to accept a somewhat leaky abstraction or less helpful diagnostics if it simplifies the implementation.
This is why `ed` doesn't bother to say anything but "?" to erroneous commands. If the user messes up, why should it be the job of the OS to handhold them? Garbage in, garbage out. That attitude may seem out of place today but consider that it came from a time when a program might have one author and 1-20 users, so their time was valued almost equally.
tredre3 22 hours ago [-]
> That attitude may seem out of place today
It absolutely doesn't. Everywhere I've worked we were instructed to give terse error messages to the user. Perhaps not a single "?", but "Oops, something went wrong!" is pretty widespread and equally unhelpful.
nine_k 4 hours ago [-]
This is normal to return a terse message to a remote user via API. The remote user may be hostile, actively trying to gather information useful for breaking in.
But the local user who operates pf is already trusted, normally it would be root.
In either case, no error should be silently swallowed. Details should be logged in a secure way, else troubleshooting becomes orders of magnitude harder.
PunchyHamster 21 hours ago [-]
> That attitude may seem out of place today
That attitude was out of place at every point. Now it was excusable when RAM and disk space was sparse, it isn't today, it have entirely drawbacks
FarmerPotato 21 hours ago [-]
Code size would balloon if you try to format verbose error messages. I often look at the binaries of old EPROMs. I notice that 1) the amount of ASCII text is a big fraction of the binary 2) still just categories (“Illegal operation”). For the 1970s, we’re talking user programs that fit in 2K.
I write really verbose diagnostic messages in my modern code.
kjellsbells 16 hours ago [-]
There was also an implicit saving back then that an error message could be looked up in some other system (typically, a printed manual). You didn't need to write 200 chars to the screen if you could display something much shorter, like SYS-3175, and be confident that the user could look that up in the manual and understand what they're being told and what to do about it.
IBM were experts at this, right up to the OS/2 days. And as machines got more powerful, it was easy to put in code to display the extra text by a lookup in a separate file/resource. Plus it made internationalization very easy.
fluoridation 23 hours ago [-]
Even in that scenario that attitude seems out of place, considering a feature is implemented once and used many times.
traceroute66 1 days ago [-]
> Does this mean that basically nobody is currently using OpenBSD in the datacentre or anywhere
Half the problem is lack of proper drivers. I love OpenBSD but all the fibre stuff is just a bit half-baked.
For a long time OpenBSD didn't even have DOM (light-level monitoring etc.) exposed in its 1g fibre drivers. Stuff like that automatically kills off OpenBSD as a choice for datacentres where DOM stats are a non-negotiable hard requirement as they are so critical to troubleshooting.
OpenBSD finally introduced DOM stats for SFP somewhere around 2020–2021, but it doesn't always work, it depends if you have the right magic combination of SFP and card manufacturer. Whilst on FreeBSD it Just Works (TM).
And then overall, for higher speed optics, FreeBSD simply remains lightyears ahead (forgive the pun !). For example, Decisio make nice little router boxes with 10g SFP+ on them, FreeBSD has the drivers out-of-the-box, OpenBSD doesn't. And that's only an SFP+ example, its basically rolling-tumbleweed in a desert territory if you start venturing up to QSFP etc. ...
CursedSilicon 1 days ago [-]
How much work is it to port drivers between Free and Open BSD?
SoftTalker 1 days ago [-]
OpenBSD doesn't allow binary blobs. So if there isn't a fully open-source driver (or adequate docs for a developer to write one), it won't happen (hence, no Nvidia support). Not sure about FreeBSD in this regard, but AFAIK most of these drivers start as ports from Linux.
traceroute66 1 days ago [-]
> How much work is it to port drivers between Free and Open BSD?
IIRC there are two problems at play:
First, I'm not a C coder so this is a bit above my pay-grade, but from what little I do remember about the subject, the problem relates to the OpenBSD requirement to adopt their security mechanisms such as pledge, unveil and strlcpy. IIRC the OpenBSD compiler is also (unsurprisingly !) more anal about stack protector W^X etc. So the porting process is perhaps more time-consuming and low-level than it might otherwise be on other porting projects.
Second, the licensing thing might come into it. OpenBSD has a high preference to most-permissive, and so things like GPL-licensed origins might not be acceptable. IIRC FreeBSD is a little more relaxed within reason ? And when you're working with network cards I would think that is perhaps hard to avoid to some extent if you're relying on certain bits being ultimately derived from Intel chipsets or whatever.
I'm open to correction by those more knowledgable than me on porting intricacies. ;)
toast0 1 days ago [-]
The difficulty of porting NIC drivers is probably not in differences in the userland API; kernel drivers don't likely pledge anything. But OpenBSD and FreeBSD diverged a long time ago, and I'd be surprised if their kernel APIs are very close anymore. How to detect and interface with devices is probably a bit different, and rx/tx packets will be different too.
I think most of the vendor supplied NIC drivers in FreeBSD are BSD licensed, so that shouldn't be an issue. I checked Intel, Melanox (now NVidia), Cavium/QLogic/Broadcom, Solarflare. The realtek driver in the tree is BSD licensed but not vendor provided; the vendor driver in ports is also BSD licensed. I'm not sure if there's a datacenter ethernet provider with in kernel drivers I missed; but I don't think license is a problem here either --- anyway you could ship a driver module out of tree if it was.
citrin_ru 1 days ago [-]
AFAIK performance is not a priority for OpenBSD project - security is (and other related qualities like code which is easy to understand and maintain). FreeBSD (at least when I followed it several years ago) had better performance both for ipfw and its own PF fork (not fully compatible with OpenBSD one).
traceroute66 1 days ago [-]
> AFAIK performance is not a priority for OpenBSD project - security is
TBF that was the case historically, but they have absolutely been putting in an effort into performance in their more recent releases.
Lots of stuff that used to be simply horrific on OpenBSD, such as multi-peer BGP full-table refreshes is SIGNIFICANTLY better in the last couple of years.
Clearly still not as good as FreeBSD, but compared to what it was...
TuxPowered 21 hours ago [-]
> not fully compatible with OpenBSD one
The OpenBSD NAT and scrub syntax, and af-to are available in FreeBSD 15.
ffk 1 days ago [-]
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.
cperciva 1 days ago [-]
pushing the hot path out to userland where you can actually scale across cores
What sort of kernel do you have which can't scale across cores?
toast0 1 days ago [-]
The big things to avoid are crossing the user/kernel divide and communication across cores.
Staying in the kernel is approximately the same as bypassing the kernel (caveats apply); for a packet filtering / smoothing use case, I don't think kernel bypass is needed. You probably want to tune NIC hashing so that inbound traffic for a given shaping queue arrives in the same NIC rx queue; but you probably want that in a kernel bypass case as well. Userspace is certainly nicer during development, as it's easier to push changes, but in 2026, it feels like traffic shaping has pretty static requirements and letting the kernel do all the work feels reasonable to me.
Otoh, OpenBSD is pretty far behind the curve on SMP and all that (I think their PF now has support for SMP, but maybe it's still in development?; I'd bet there's lots of room to reduce cross core communication as well, but I haven't examined it). You can't pin userspace cores to cpus, I doubt their kernel datastructures are built to reduce communications, etc. Kernel bypass won't help as much as you would hope, if it's available, which it might not be, because you can't control the userspace to limit cross core communications.
rpcope1 1 days ago [-]
Just a single data point, but the BSDs in general, as much as people like to jerk them off, having tested both recent FreeBSD (which should be much faster than OpenBSD) and Debian on I guess the now kind of elderly APU2s I have, netfilter is noticably faster (and I find nftables to be frankly less challenging than pf) and gets those devices right at gigabit line speed even with complex firewall rules, where as pf leaves performance on the table. It probably has to do with the fact it's an older 4 core design that wasn't super high power to begin with (does still does its job extremely well), but still.
toast0 1 days ago [-]
One issue I've seen from a fair number of people on the APU2s running FreeBSD is if they've got PPPoE; inbound traffic (at least) all hashes to the same RX queue, and as a result there's no parallelism... if you're on gigE fiber with PPPoE, the APU2 can't really keep up single threaded. The earlier APU (1) boards use realtek nics that I think only have a single queue, so you won't get effective parallelism there either. If I'm finding the right information, APU2s with i210 have 4 rx queues which is well matched with a quad core, but those with i211 only have 2 rx queues, which means half of the processors will have nothing to do unless your kernel redistributes packets after rxing, but that comes at a cost too.
Linux may have a different packet flow, or netfilter could be faster than pf.
> I find nftables to be frankly less challenging than pf
I also don't really care for how pf specifies rules. I would rather run ipfw, but pf has pfsync whereas ipfw doesn't have a way to do failover with state synchronization for stateful firewalls/NAT. So I figured out how to express my rules in pf.conf; because it was worth it, even if I don't like it :P
asmnzxklopqw 1 days ago [-]
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.
zie 16 hours ago [-]
> Linux is more welcoming to new users. And the difference is only growing.
Unless you want documentation. :) Linux documentation is ALL over the place, and it's hard to know if X docs apply to your particular mess.
On OpenBSD it's `man <thing>` and you get your docs. Yes man exists on Linux, but lots of tools, especially "new" stuff or linux specific stuff doesn't come with man pages and those that do have man pages, can be missing lots of stuff.
Systemd docs tend to be somewhat useless, missing all sorts of stuff. Troubleshooting systemd by reading the docs is usually a waste of time. Reading the source code or getting lucky with a web search is usually your only hope.
"OpenBSD does not want to attract GNU newbies." misc@
And that's IMHO is a good thing.
atmosx 1 days ago [-]
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.
toast0 1 days ago [-]
> 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?
This looks like it only affects bandwidth limiting. I suspect it's pretty niche to use OpenBSD as a traffic shaper at 10G+, and if you did, I'd imagine most of the queue limits would tend toward significantly less than 4G.
IcePic 1 days ago [-]
One thing could also be that by the time you have 10GE uplinks, shaping is not as important.
When we had 512kbit links, prioritizing VOIP would be a thing, and for asymmetric links like 128/512kbit it was prudent to prioritize small packets (ssh) and tcp ACKs on the outgoing link or the downloads would suffer, but when you have 5-10-25GE, not being able to stick an ACK packet in the queue is perhaps not the main issue.
hrmtst93837 1 days ago [-]
At 10G and up, shaping still matters. Once you mix backups, CCTV, voice, and customer circuits on the same uplink, a brief saturation event can dump enough queueing delay into the path that the link looks fine on paper while the stuff people actually notice starts glitching, and latency budgets is tight. Fat pipes don't remove the need for control, they just make the billing mistake more expensive.
Melatonic 1 days ago [-]
At this level wouldnt a proper implementation be segregating the link into multiple VMs (or jails?) ? Or is that the same thing on BSD?
lazide 14 hours ago [-]
And how would you propose doing that? Note: what do you think the feature essentially does?
Melatonic 1 days ago [-]
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
SoftTalker 1 days ago [-]
It's widely used as a router, that's one of its primary uses. But not sure to what scale, likely at small orgs not at major ISPs.
But, OpenBSD is a project by and for its developers. They use it and develop it to do what they want; they don't really care what anyone else does or doesn't do with it.
Melatonic 23 hours ago [-]
Do people actually use OpenBSD over FreeBSD for use as a router ?
zie 16 hours ago [-]
Yes, lots of large providers really want defense in depth at the router/firewall/important services level.
They want separate OS's in case a giant CVE or bug comes out for platform X but isn't on platform Y. So multi-platform core services is a key component of systems that need to stay up and alive long-term. Things like Routers, Firewalls, DNS, BGP, etc. Use different software and hardware stacks.
We use FreeBSD and Debian @ work, though we are playing around with Nix and Guix now to maybe replace the Debian someday.
lstodd 1 days ago [-]
You don't need 4gbps pf queues or even fiber on every single machine in a datacenter. So be surprised, it is used widely for its simplicity and reliability not to mention security compared to those proprietary implementations you speak of, may they rot in hell.
daneel_w 22 hours ago [-]
Not every in-and-out must pass through a queue in PF. The limitation specifically affected throughput of queues.
PunchyHamster 21 hours ago [-]
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.
JumpingVPN2027 4 hours ago [-]
It’s interesting how much of networking behavior still assumes a relatively stable path.
In practice, especially on mobile networks, path instability is the norm rather than the exception.
Feels like a lot of system design still treats failure as exceptional, while it might make more sense to treat it as a normal runtime condition.
haunter 1 days ago [-]
My local fiber finally offers 4 Gbps connection but I’m not even sure what to use it for lol. I have 2 Gbps and that's more than enough already.
shpingbing 1 days ago [-]
I finally talked myself into going to 3Gbps (and working on internal network to 10). Internal transfer to NAS will be much faster, and downloading AI models should go from ~8 minutes to less than 3 minutes. Is it necessary? Not exactly. But super nice
darknavi 1 days ago [-]
I do nightly offsite mirroring (just to a cloud provider) and making that go faster and not cannibalize all of my throughput is nice.
rayiner 1 days ago [-]
Can pf actually shape at speeds above 4 gbps?
daneel_w 20 hours ago [-]
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.
razighter777 1 days ago [-]
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.
gigatexal 1 days ago [-]
It’s still single threaded. PF in FreeBSD is multithreaded. For home wan’s I’d be using openBSD. For anything else FreeBSD.
robutsume 22 hours ago [-]
[dead]
riteshyadav02 1 days ago [-]
[dead]
mdavidyu 1 days ago [-]
[dead]
PracticAIl45 23 hours ago [-]
[dead]
AIinfoclip14 19 hours ago [-]
[dead]
gethwhunter34 23 hours ago [-]
[dead]
Heer_J 1 days ago [-]
[dead]
Heer_J 1 days ago [-]
[dead]
holdtman47 1 days ago [-]
[dead]
jamesvzb 1 days ago [-]
[dead]
bell-cot 1 days ago [-]
"Values up to 999G are supported, more than enough for interfaces today and the future." - Article
"When we set the upper limit of PC-DOS at 640K, we thought nobody would ever need that much memory." - Bill Gates
throw0101d 1 days ago [-]
> "Values up to 999G are supported, more than enough for interfaces today and the future." - Article
Especially given that IEEE 802.3dj is working on 1.6T / 1600G, and is expected to publish the final spec in Summer/Autumn 2026:
Currently these interfaces are only on switches, but there are already NICs at 800G (P1800GO, Thor Ultra, ConnectX-8/9), so if you LACP/LAGG two together your bond is at 1600G.
arsome 1 days ago [-]
If you're moving those kind of speeds you're probably not doing packet filtering in software.
throw0101d 1 days ago [-]
But you may be using Unix-y software to manage the interfaces and do offload programming:
I use VPP and handle bonded speeds of 200gbit. Not that far fetched to also do this at 1000gbit.
mulmen 1 days ago [-]
Probably? But if you are then you’re certainly not using OpenBSD.
bitfilped 1 days ago [-]
Yes, we're already running 800G networks, so this phrasing seems really silly to me.
WhyNotHugo 1 days ago [-]
Honestly, I'm really curious about this number. 10bits is 1024, so why 999G specifically?
abound 1 days ago [-]
Looking at the patch itself (linked in the article), the description has this:
> We now support configuring bandwidth
up to ~1 Tbps (overflow in m2sm at m > 2^40).
So I think that's it, 2^40 is ~1.099 trillion
elevation 1 days ago [-]
Looks like an arbitrary validation cap. By the time we're maxing out the 64-bit underlying representation we probably won't be using Ethernet any more.
palmotea 1 days ago [-]
> By the time we're maxing out the 64-bit underlying representation we probably won't be using Ethernet any more.
We will be using Ethernet until the heat death of the universe, if we survive that long.
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.
I guess few people with faster ports felt the need to limit bandwidth for a service to something that’s that large.
FTA:
“OpenBSD's PF packet filter has long supported HFSC traffic shaping with the queue rules in pf.conf(5). However, an internal 32-bit limitation in the HFSC service curve structure (struct hfsc_sc) meant that bandwidth values were silently capped at approximately 4.29 Gbps, ” the maximum value of a u_int ".
With 10G, 25G, and 100G network interfaces now commonplace, OpenBSD devs making huge progress unlocking the kernel for SMP, and adding drivers for cards supporting some of these speeds, this limitation started to get in the way. Configuring bandwidth 10G on a queue would silently wrap around, producing incorrect and unpredictable scheduling behaviour.
A new patch widens the bandwidth fields in the kernel's HFSC scheduler from 32-bit to 64-bit integers, removing this bottleneck entirely.”
Now I'm more scared to use OpenBSD than I was a minute before.
I strongly prefer software that fails loudly and explicitly.
Also,
is valid, and will do a narrowing conversion. I don’t think compilers are required to warn about that.Regardless of how good the philosophy of something is, if it's as niche and manpower constrained as OpenBSD is then it's going to accumulate problems like this.
That is, "worse is better" and it's okay to accept a somewhat leaky abstraction or less helpful diagnostics if it simplifies the implementation.
This is why `ed` doesn't bother to say anything but "?" to erroneous commands. If the user messes up, why should it be the job of the OS to handhold them? Garbage in, garbage out. That attitude may seem out of place today but consider that it came from a time when a program might have one author and 1-20 users, so their time was valued almost equally.
It absolutely doesn't. Everywhere I've worked we were instructed to give terse error messages to the user. Perhaps not a single "?", but "Oops, something went wrong!" is pretty widespread and equally unhelpful.
But the local user who operates pf is already trusted, normally it would be root.
In either case, no error should be silently swallowed. Details should be logged in a secure way, else troubleshooting becomes orders of magnitude harder.
That attitude was out of place at every point. Now it was excusable when RAM and disk space was sparse, it isn't today, it have entirely drawbacks
I write really verbose diagnostic messages in my modern code.
IBM were experts at this, right up to the OS/2 days. And as machines got more powerful, it was easy to put in code to display the extra text by a lookup in a separate file/resource. Plus it made internationalization very easy.
Half the problem is lack of proper drivers. I love OpenBSD but all the fibre stuff is just a bit half-baked.
For a long time OpenBSD didn't even have DOM (light-level monitoring etc.) exposed in its 1g fibre drivers. Stuff like that automatically kills off OpenBSD as a choice for datacentres where DOM stats are a non-negotiable hard requirement as they are so critical to troubleshooting.
OpenBSD finally introduced DOM stats for SFP somewhere around 2020–2021, but it doesn't always work, it depends if you have the right magic combination of SFP and card manufacturer. Whilst on FreeBSD it Just Works (TM).
And then overall, for higher speed optics, FreeBSD simply remains lightyears ahead (forgive the pun !). For example, Decisio make nice little router boxes with 10g SFP+ on them, FreeBSD has the drivers out-of-the-box, OpenBSD doesn't. And that's only an SFP+ example, its basically rolling-tumbleweed in a desert territory if you start venturing up to QSFP etc. ...
IIRC there are two problems at play:
First, I'm not a C coder so this is a bit above my pay-grade, but from what little I do remember about the subject, the problem relates to the OpenBSD requirement to adopt their security mechanisms such as pledge, unveil and strlcpy. IIRC the OpenBSD compiler is also (unsurprisingly !) more anal about stack protector W^X etc. So the porting process is perhaps more time-consuming and low-level than it might otherwise be on other porting projects.
Second, the licensing thing might come into it. OpenBSD has a high preference to most-permissive, and so things like GPL-licensed origins might not be acceptable. IIRC FreeBSD is a little more relaxed within reason ? And when you're working with network cards I would think that is perhaps hard to avoid to some extent if you're relying on certain bits being ultimately derived from Intel chipsets or whatever.
I'm open to correction by those more knowledgable than me on porting intricacies. ;)
I think most of the vendor supplied NIC drivers in FreeBSD are BSD licensed, so that shouldn't be an issue. I checked Intel, Melanox (now NVidia), Cavium/QLogic/Broadcom, Solarflare. The realtek driver in the tree is BSD licensed but not vendor provided; the vendor driver in ports is also BSD licensed. I'm not sure if there's a datacenter ethernet provider with in kernel drivers I missed; but I don't think license is a problem here either --- anyway you could ship a driver module out of tree if it was.
TBF that was the case historically, but they have absolutely been putting in an effort into performance in their more recent releases.
Lots of stuff that used to be simply horrific on OpenBSD, such as multi-peer BGP full-table refreshes is SIGNIFICANTLY better in the last couple of years.
Clearly still not as good as FreeBSD, but compared to what it was...
The OpenBSD NAT and scrub syntax, and af-to are available in FreeBSD 15.
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.
What sort of kernel do you have which can't scale across cores?
Staying in the kernel is approximately the same as bypassing the kernel (caveats apply); for a packet filtering / smoothing use case, I don't think kernel bypass is needed. You probably want to tune NIC hashing so that inbound traffic for a given shaping queue arrives in the same NIC rx queue; but you probably want that in a kernel bypass case as well. Userspace is certainly nicer during development, as it's easier to push changes, but in 2026, it feels like traffic shaping has pretty static requirements and letting the kernel do all the work feels reasonable to me.
Otoh, OpenBSD is pretty far behind the curve on SMP and all that (I think their PF now has support for SMP, but maybe it's still in development?; I'd bet there's lots of room to reduce cross core communication as well, but I haven't examined it). You can't pin userspace cores to cpus, I doubt their kernel datastructures are built to reduce communications, etc. Kernel bypass won't help as much as you would hope, if it's available, which it might not be, because you can't control the userspace to limit cross core communications.
Linux may have a different packet flow, or netfilter could be faster than pf.
> I find nftables to be frankly less challenging than pf
I also don't really care for how pf specifies rules. I would rather run ipfw, but pf has pfsync whereas ipfw doesn't have a way to do failover with state synchronization for stateful firewalls/NAT. So I figured out how to express my rules in pf.conf; because it was worth it, even if I don't like it :P
Unless you want documentation. :) Linux documentation is ALL over the place, and it's hard to know if X docs apply to your particular mess.
On OpenBSD it's `man <thing>` and you get your docs. Yes man exists on Linux, but lots of tools, especially "new" stuff or linux specific stuff doesn't come with man pages and those that do have man pages, can be missing lots of stuff.
Systemd docs tend to be somewhat useless, missing all sorts of stuff. Troubleshooting systemd by reading the docs is usually a waste of time. Reading the source code or getting lucky with a web search is usually your only hope.
On FreeBSD you get `man <thing>` AND you get the FreeBSD handbook: https://docs.freebsd.org/en/books/handbook/
And that's IMHO is a good thing.
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.
This looks like it only affects bandwidth limiting. I suspect it's pretty niche to use OpenBSD as a traffic shaper at 10G+, and if you did, I'd imagine most of the queue limits would tend toward significantly less than 4G.
When we had 512kbit links, prioritizing VOIP would be a thing, and for asymmetric links like 128/512kbit it was prudent to prioritize small packets (ssh) and tcp ACKs on the outgoing link or the downloads would suffer, but when you have 5-10-25GE, not being able to stick an ACK packet in the queue is perhaps not the main issue.
But, OpenBSD is a project by and for its developers. They use it and develop it to do what they want; they don't really care what anyone else does or doesn't do with it.
They want separate OS's in case a giant CVE or bug comes out for platform X but isn't on platform Y. So multi-platform core services is a key component of systems that need to stay up and alive long-term. Things like Routers, Firewalls, DNS, BGP, etc. Use different software and hardware stacks.
We use FreeBSD and Debian @ work, though we are playing around with Nix and Guix now to maybe replace the Debian someday.
In practice, especially on mobile networks, path instability is the norm rather than the exception.
Feels like a lot of system design still treats failure as exceptional, while it might make more sense to treat it as a normal runtime condition.
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.
"When we set the upper limit of PC-DOS at 640K, we thought nobody would ever need that much memory." - Bill Gates
Especially given that IEEE 802.3dj is working on 1.6T / 1600G, and is expected to publish the final spec in Summer/Autumn 2026:
* https://en.wikipedia.org/wiki/Terabit_Ethernet
Currently these interfaces are only on switches, but there are already NICs at 800G (P1800GO, Thor Ultra, ConnectX-8/9), so if you LACP/LAGG two together your bond is at 1600G.
* https://en.wikipedia.org/wiki/Vector_Packet_Processing
* https://www.youtube.com/watch?v=ptm9h-Lf0gg ("VPP: A 1Tbps+ router with a single IPv4 address")
* https://en.wikipedia.org/wiki/Cumulus_Networks
> We now support configuring bandwidth up to ~1 Tbps (overflow in m2sm at m > 2^40).
So I think that's it, 2^40 is ~1.099 trillion
We will be using Ethernet until the heat death of the universe, if we survive that long.
Calling something "Ethernet" amounts to a promise that:
- From far enough up the OSI sandwich*, you can pretend that it's a magically-faster version of old-fashioned Ethernet
- It sticks to broadly accepted standards, so you won't get bitten by cutting-edge or proprietary surprises
*https://en.wikipedia.org/wiki/OSI_model
Isn't this anachronistic for 2026? Am I misunderstand what this means?