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

51–60 of 74 posts

Re: OpenBSD: PF queues break the 4 Gbps barrier

#51

Post by toast0 »

rpcope1 wrote: post #49
toast0 wrote: post #35

Earlier quoted context omitted.

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

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

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

Re: OpenBSD: PF queues break the 4 Gbps barrier

#53

Post by darknavi »

shpingbing wrote: post #43
haunter wrote: post #30

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.

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

I do nightly offsite mirroring (just to a cloud provider) and making that go faster and not cannibalize all of my throughput is nice.

Re: OpenBSD: PF queues break the 4 Gbps barrier

#54

Post by fluoridation »

muvlon wrote: post #38
kaashif wrote: post #32

Earlier quoted context omitted.

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.

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…

Even in that scenario that attitude seems out of place, considering a feature is implemented once and used many times.

Re: OpenBSD: PF queues break the 4 Gbps barrier

#55

Post by Melatonic »

SoftTalker wrote: post #45
Melatonic wrote: post #40

Earlier quoted context omitted.

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

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.

Do people actually use OpenBSD over FreeBSD for use as a router ?

Re: OpenBSD: PF queues break the 4 Gbps barrier

#58

Post by daneel_w »

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…

Not every in-and-out must pass through a queue in PF. The limitation specifically affected throughput of queues.

Re: OpenBSD: PF queues break the 4 Gbps barrier

#60

Post by tredre3 »

muvlon wrote: post #38
kaashif wrote: post #32

Earlier quoted context omitted.

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.

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…

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

Post reply on HN