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

Mon Dec 8 02:23:02 UTC 2014

> On Dec 7, 2014, at 5:09 PM, Martin Hanson <greencoppermine at yandex.com> wrote:
> 
>> Given you appear to believe you are well acquainted with the problem, why
>> not pull your finger out of your proverbial and sort it yourself?
> 
> LOL, good one!
> 
> Seems like you have missed the whole point, nobody can sort it out now!

No, you’re missing the point.

The codebase has forked, and it’s unlikely that anyone who is working on (or in a position to direct work on) pf believes that the correct course of action is to reverse at this point, and follow your prescriptive.

However, there is an architecture available (pfill) which will allow you, or someone you find to do the work, to bring the current “pf” from OpenBSD work into FreeBSD.  Given this, I’m left to ask why you continue to pound the desk with demands when there is a path by which you can accomplish your goal.   The other question, of course, is to ask you what is lacking in OpenBSD that you can’t use that for your firewalling needs, given your obsequiousness toward OpenBSD.

To directly counter your assertion, I suggest you read
http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006643.html
http://lists.freebsd.org/pipermail/svn-src-projects/2012-April/005056.html
http://lists.freebsd.org/pipermail/freebsd-questions/2014-August/259703.html

and this thread from this past Summer:  http://lists.freebsd.org/pipermail/freebsd-pf/2014-July/007393.html

Where I respond to "Anyone working on bringing FreeBSD up to 5.6?” in part with:

> There was some brief discussion of same at vBSD (prompted by Henning’s rant after being
> pushed about his claims about the “pf” in OpenBSD being faster than the “pf” in FreeBSD 10).
>         This occurred both at ruBSD and vBSD
> 
>         http://tech.yandex.ru/events/yagosti/ruBSD/talks/1477/  (you can skip to 29:51)
>         http://tech.yandex.ru/events/yagosti/ruBSD/talks/1488/ (you can skip to 33:18 and 36:53 for the salient bits)
>         http://quigon.bsws.de/papers/2013/vbsdcon/
>         http://quigon.bsws.de/papers/2013/rubsd/
> 
> bapt apparently volunteered to attempt to bring the pf from a more modern pf to FreeBSD.  You’ll have to ask him about status.

And if you want to read nothing else, read this thread:
https://lists.freebsd.org/pipermail/freebsd-pf/2012-September/006740.html

Wherein, Gleb was specifically asked about doing >exactly< as you request, by several people, and directly rejected same.  (A minor skirmish broke out between Gleb and Ermal, and Gleb got a bit … well, let’s just say it can make one squeamish to watch.  https://lists.freebsd.org/pipermail/freebsd-pf/2012-September/006754.html  Let’s just say that Gleb should offer an apology to Ermal for that, and that Ermal had other things happening during that period.)

The salient points are that:  a) your assertion is not new, b) work continues, and c) there is likely more low-hanging fruit: 
http://lists.freebsd.org/pipermail/freebsd-net/2013-April/035417.html

Given this, (and all of the above), it is unlikely that the current course will be abandoned, as you demand.  The two main people working on pf (Ermal and Gleb) are both still working on it.

> On Dec 7, 2014, at 9:52 AM, Martin Hanson <greencoppermine at yandex.com> wrote:

> OpenBSD will eventually get multicore support, no doubt about that, but the difference is that once they do, they do it RIGHT!

One of the frustrating things about your statement here is that you imply that the multicore support in FreeBSD is not “right”.  That is is, for reasons unstated, somehow lacking.

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 

OpenBSD and FreeBSD have different goals.   To quote: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html#AEN1248
The FreeBSD Project targets "production quality commercial off-the-shelf (COTS) workstation, server, and high-end embedded systems”

OpenBSD doesn’t seem to be concerned about performance of pf:  http://www.openbsd.org/faq/pf/perf.html

Even with the multi-core processing, neither ipfw or pf is what it needs to be.  Neither will deal with the 1.488Mpps of 1Gbps Ethernet.
http://bsdrp.net/documentation/examples/forwarding_performance_lab_of_an_ibm_system_x3550_m3_with_intel_82580

Nor are we done with pf.  One of the short-term goals is to improve performance by creating a per-core state-table, rather than locking a single state table in RAM.  Another is to investigate
the effects of thread-pinning, as well as getting correct RSS mechanisms in the kernel such that a given (set of) flow(s) are always directed at the same core.

One of the largest issues with the common open-source packet filters is that they tightly couple the flow classification and treatment, i.e. after flows are classified actions are executed locally immediately after the classification.  While we might get to 1Gbps (with some work) via this route, or even slightly above, I find it unlikely that we can get anywhere near the 14.88Mpps required to correctly process 10Gbps Ethernet at line rate using the same architecture.

Have you studied the problem, Martin?  Or are you going to continue to beat the “OpenBSD über alles” drum?

Jim