From owner-freebsd-pf@FreeBSD.ORG Mon Dec 8 02:23:02 2014 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D84E5396 for ; Mon, 8 Dec 2014 02:23:02 +0000 (UTC) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F5C633F for ; Mon, 8 Dec 2014 02:23:02 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id va2so2938757obc.22 for ; Sun, 07 Dec 2014 18:23:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=+N0d31OaddR5j1DzWNuNnoFfe++JHvVAi/1R+8me9lA=; b=L7aMrXzRxxcG2SmZJfNXRK98aBheukKfeMrcuTWb+9RIcHGILEpxCGyrqug7u0Lwin FO9CjnqW77p8v0qziPYFKjFuXuxPHTu2atRvlDAsVpiRe9FdhCmEsg0voH5J/S0lGcAa F5fAFanSGanpwpNiZO+VyWM4kP9jABINWAo2S0nWMfQRHPSTydFllVkXwYdaq5/jHTQd gM+aRoo2axIXvgqyqv9a5MrWMjDlyAaoOdjSZ5zqtO+fXGwUtFbivxkd9bCI4WrslCS0 sBgR/+QGv2Mm+OMrEl+V0w40hDnrzk4jE7rbvrcOLc5zl06VRXOcd7QHyMOyaajIG+1/ TjtQ== X-Gm-Message-State: ALoCoQlUvHbMV+0R+pFSR+vR7NGJ7ioeToV4m5ovIa0xyC4lJ8yJxKLXyrfwLzN1OXM+a/vYZXDN X-Received: by 10.202.98.10 with SMTP id w10mr5463285oib.104.1418005380869; Sun, 07 Dec 2014 18:23:00 -0800 (PST) Received: from ?IPv6:2610:160:11:33:8d68:8c2c:b451:393e? ([2610:160:11:33:8d68:8c2c:b451:393e]) by mx.google.com with ESMTPSA id mq4sm17628571obb.22.2014.12.07.18.22.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Dec 2014 18:23:00 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2058.2\)) Subject: Re: Why merging recent OpenBSD PF code is not easy (was Re: FOLLOW-UP) From: Jim Thompson In-Reply-To: <115251417993747@web27m.yandex.ru> Date: Sun, 7 Dec 2014 20:22:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <75F1B874-8BF5-4500-A9EB-9A6E3F90C3F2@netgate.com> References: <115251417993747@web27m.yandex.ru> To: Martin Hanson X-Mailer: Apple Mail (2.2058.2) Cc: freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 02:23:02 -0000 > On Dec 7, 2014, at 5:09 PM, Martin Hanson = 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 = 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