Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Dec 2014 20:22:58 -0600
From:      Jim Thompson <jim@netgate.com>
To:        Martin Hanson <greencoppermine@yandex.com>
Cc:        freebsd-pf@freebsd.org
Subject:   Re: Why merging recent OpenBSD PF code is not easy (was Re: FOLLOW-UP)
Message-ID:  <75F1B874-8BF5-4500-A9EB-9A6E3F90C3F2@netgate.com>
In-Reply-To: <115251417993747@web27m.yandex.ru>
References:  <115251417993747@web27m.yandex.ru>

next in thread | previous in thread | raw e-mail | index | archive | help

> On Dec 7, 2014, at 5:09 PM, Martin Hanson <greencoppermine@yandex.com> =
wrote:
>=20
>> 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?
>=20
> LOL, good one!
>=20
> Seems like you have missed the whole point, nobody can sort it out =
now!

No, you=E2=80=99re missing the point.

The codebase has forked, and it=E2=80=99s 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 =E2=80=9Cpf=E2=
=80=9D from OpenBSD work into FreeBSD.  Given this, I=E2=80=99m 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=E2=80=99t 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.ht=
ml

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?=E2=80=9D=
 in part with:

> There was some brief discussion of same at vBSD (prompted by =
Henning=E2=80=99s rant after being
> pushed about his claims about the =E2=80=9Cpf=E2=80=9D in OpenBSD =
being faster than the =E2=80=9Cpf=E2=80=9D in FreeBSD 10).
>         This occurred both at ruBSD and vBSD
>=20
>         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/
>=20
> bapt apparently volunteered to attempt to bring the pf from a more =
modern pf to FreeBSD.  You=E2=80=99ll 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 =E2=80=A6 =
well, let=E2=80=99s just say it can make one squeamish to watch.  =
https://lists.freebsd.org/pipermail/freebsd-pf/2012-September/006754.html =
 Let=E2=80=99s 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:=20
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@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 =E2=80=9Cright=E2=80=9D=
.  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=E2=80=99s =E2=80=9Cpf=E2=80=9D doesn=E2=80=99t even handle 1Gbps =
unless=20

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

OpenBSD doesn=E2=80=99t 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_i=
bm_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 =E2=80=9COpenBSD =C3=BCber alles=E2=80=9D drum?

Jim







Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?75F1B874-8BF5-4500-A9EB-9A6E3F90C3F2>