From owner-freebsd-pf@FreeBSD.ORG Thu Sep 6 07:08:08 2012 Return-Path: Delivered-To: pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DAEA106564A; Thu, 6 Sep 2012 07:08:08 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 88CF58FC0A; Thu, 6 Sep 2012 07:08:07 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q867860v036324; Thu, 6 Sep 2012 11:08:06 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q86786eu036323; Thu, 6 Sep 2012 11:08:06 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 6 Sep 2012 11:08:06 +0400 From: Gleb Smirnoff To: Ermal Lu?i Message-ID: <20120906070806.GM15915@glebius.int.ru> References: <20120905115140.GF15915@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: pf@FreeBSD.org, net@FreeBSD.org Subject: Re: [HEADS UP] merging projects/pf into head X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Thu, 06 Sep 2012 07:08:08 -0000 Ermal, On Wed, Sep 05, 2012 at 10:09:23PM +0200, Ermal Lu?i wrote: E> Its good to see results on your work and is good moving forward. E> Claiming better behavior, under DoS or other comparison without showing any data E> or technical reason is a bit over this RFC. Benchmark by authors are always biased, thus I didn't boast about results. Much better if benchmarking is performed by someone else. If you insist here is some data: 1) Casting UDP flood of 400k states in this simple setup: [box A] -> [pf] -> [blackhole] On my particular box, head pf can forward 520 kpps and anything above is lost. SMP-pf can do 980 kpps. If we increase number of states, results would be more dramatic. If we make load bidirectional (which is the case in 99%) results would be more dramatic. Increasing number of rx/tx threads (more NICs, or more smart NICs) as well as increasing number of CPUs would make results even more dramatic. 2) DoSes Results are just empirical. At my job, when running old pf and encountering DoS attack, we usually notice that by bad web sites responsibility, customers complaining, etc. The box under attack is very unresponsive via ssh. With new SMP-pf a DoS may come in and if it doesn't consume entire bandwidth it can be noticed only post-factum when looking at monitoring plots. I'd appreciate if you perform benchmarking and testing. As said above, results from author are usually biased, but results from opponents more interesting. E> > 1) Move pf out of contrib. E> I do not see a reason behind this, any particular reason? It is no longer contributed source, but source developed by the FreeBSD project. E> > 2) Refactor the pfvar.h into pf.h and pf_var.h. Provide stable E> > kernel<->pfctl ABI. And probably other clean up tasks. E> Just this reason is a bit contradictory with 1) above! E> Let alone what does this mean to the user?! Nothing? E> They are after syntax stability, not breaking their machines on E> upgrade, ABI is nothing to them. Do you understand that "absense of stable ABI" == "breaking machines after upgrade"? Right now, the structures supplied via ioctl() include many fields that aren't related to API, but are internal kernel. Any internal kernel change breaks ABI. If new API structures are introduced, then we can do a lot of hacking on pf in 11.0-CURRENT with ability to safely merge changes to 10.0-STABLE. -- Totus tuus, Glebius.