Why merging recent OpenBSD PF code is not easy (was Re: FOLLOW-UP)

[Maxim Khitrov]

On Sun, Dec 7, 2014 at 9:22 PM, Jim Thompson <jim at netgate.com> wrote:
> OpenBSD may eventually grow proper multicore support, but that is of little concern to the FreeBSD project.   It took FreeBSD years to get proper multicore support, and I doubt
> OpenBSD gets there any faster.  Nor have they started. This is bad news for OpenBSD, because the world is now multicore, 1Gbps are common (I have one to my house) and 10Gbps connections are increasingly common.   OpenBSD’s “pf” doesn’t even handle 1Gbps unless

How many of your 1 Gbps links are handling 1.488 Mpps? I wasn't very
interested in that use case when I did my testing, so for me, OpenBSD
5.3 handled 4.2 Gbps (MTU 1500) with Intel X540 NIC and Xeon
E3-1275v2. If I did the math right, that's ~0.35 Mpps:

http://marc.info/?l=openbsd-misc&m=137600809910496&w=2

The limiting factor was not pf (nearly same performance with it
disabled), but single-core processing of all interrupts and packets.
Yes, there is work to be done there.

Even with that "poor" performance, I'm now using OpenBSD for firewalls
because the new pf.conf syntax, which makes the ruleset much cleaner
and easier to maintain, as well as other features (interface groups,
set prio, new queueing system, received-on, etc.), are more important
to me than being able to push 10 Gbps of traffic through the box. I
understand that other people and organizations have other priorities,
but IMHO, OpenBSD covers the common use case better than FreeBSD at
the moment. How many people managed to figure out hfsc for altq (which
isn't even compiled into the GENERIC kernel)? I tried... I really did.
Even with cbq, the resulting ruleset was an unmaintainable mess most
of the time.