Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenBSD: PF queues break the 4 Gbps barrier

undeadly.org

Post reply on HN
Print view View original

21–30 of 74 posts

Re: OpenBSD: PF queues break the 4 Gbps barrier

#21

Post by himata4113 »

arsome wrote: post #12
throw0101d wrote: post #5

Earlier quoted context omitted.

> "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: * 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 t…

If you're moving those kind of speeds you're probably not doing packet filtering in software.

I use VPP and handle bonded speeds of 200gbit. Not that far fetched to also do this at 1000gbit.

Re: OpenBSD: PF queues break the 4 Gbps barrier

#22

Post by traceroute66 »

citrin_ru wrote: post #13
ralferoo wrote: post #11

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 sur…

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).

> 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...

Re: OpenBSD: PF queues break the 4 Gbps barrier

#26

Post by nine_k »

Someone wrote: post #20
ralferoo wrote: post #11

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 sur…

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 servi…

> 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.

Re: OpenBSD: PF queues break the 4 Gbps barrier

#28

Post by ffk »

ralferoo wrote: post #11

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 sur…

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.

Re: OpenBSD: PF queues break the 4 Gbps barrier

#29

Post by CursedSilicon »

traceroute66 wrote: post #19
ralferoo wrote: post #11

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 sur…

> 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-negot…

How much work is it to port drivers between Free and Open BSD?
Post reply on HN