From owner-svn-src-projects@FreeBSD.ORG Sat Dec 8 15:07:47 2012 Return-Path: Delivered-To: svn-src-projects@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63B7B6E1; Sat, 8 Dec 2012 15:07:47 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id CE4038FC12; Sat, 8 Dec 2012 15:07:46 +0000 (UTC) Received: from rnote.ddteam.net (184-57-135-95.pool.ukrtel.net [95.135.57.184]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 9AB11C492D; Sat, 8 Dec 2012 17:07:44 +0200 (EET) Date: Sat, 8 Dec 2012 17:07:36 +0200 From: Aleksandr Rybalko To: David Chisnall Subject: Re: svn commit: r243914 - projects/bpfjit Message-Id: <20121208170736.f9abd2c1.ray@freebsd.org> In-Reply-To: <2434306D-5AC7-4624-B9E8-7C682350B78F@theravensnest.org> References: <201212052312.qB5NC2Hn056351@svn.freebsd.org> <20121206084936.GA58940@freebsd.org> <50C0DFB0.6030007@FreeBSD.org> <20121208152447.5b2958d2.ray@freebsd.org> <2434306D-5AC7-4624-B9E8-7C682350B78F@theravensnest.org> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: svn-src-projects@FreeBSD.org, Aleksandr Rybalko , src-committers@FreeBSD.org, Roman Divacky , Jung-uk Kim X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 15:07:47 -0000 On Sat, 8 Dec 2012 14:02:45 +0000 David Chisnall wrote: > On 8 Dec 2012, at 13:24, Aleksandr Rybalko wrote: > > > On Thu, 06 Dec 2012 13:10:56 -0500 > > Jung-uk Kim wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> On 2012-12-06 03:49:36 -0500, Roman Divacky wrote: > >>> Hi, > >>> > >>> David Chisnall started bpf jitter based on llvm. You can check it > >>> out here: > >>> > >>> http://people.freebsd.org/~theraven/bpfjit/ > >>> > >>> > >>> It's based on the idea of jitting the code in userspace and > >>> passing the resulting code to the kernel via some interface (this > >>> part is not done yet). > >> > >> Long time ago (about 10 years ago), I implemented something like > >> that (i.e., compile BPF program to native machine code in > >> userspace, then upload to kernel space) for my $job but I quickly > >> replace it with BPF_JITTER for several reasons. First of all, > >> there is a big security risk. A BPF filter program can be easily > >> validated by kernel with bpf_validate(9). We cannot do that for > >> native machine code and we must not allow uploading arbitrary code > >> to kernel space. You may say it is well protected by /dev/bpf > >> permissions but it is not good enough, i.e., all you need is read > >> permission to inject code to kernel space. > >> Second, LLVM is too heavy for BPF filter machine. For example, > > > > +1 > > Embedded FreeBSD will lost BPF if LLVM will be used for > > compilation :) > > Really? I've run LLVM JITs for more complex languages than BPF on > machines with only 128MB of RAM. LLVM itself takes about 5MB of > storage space and 20MB of RAM (used only during compilation, unloaded > immediately afterwards). One REALLY embedded systems, the filter > rules can be run on another host and provided in the form of a kernel > module using exactly the same code. What about systems with total 8MB of flash and 32MB of RAM (maybe even 4MB and 16MB)? :) > > >> libtrace did that long ago: > >> > >> http://www.wand.net.nz/trac/libtrace/changeset/1586 > >> > >> Someone actually benchmarked it with other JIT implementations: > >> > >> http://carnivore.it/2011/12/28/bpf_performance > > Reading the description there, I found it hard to believe that > someone had actually written that LLVM implementation. It is a case > study in how not to implement an LLVM JIT. > > >> LLVM compilation took too much time to be useful: > >> > >> engine filter cycles compile cycles > >> - ---------------+---------------+---------------- > >> jit-linux 106468 33126+72796 > >> jit-freebsd 113958 48292+72796 > >> llvm 157394 380843640+72796 > >> pcap 276910 72796 > >> linux 351391 9245+72796 > >> > >> I haven't tried theraven's implementation but I am afraid the > >> result may be similar. On top of that, it cannot be easily > >> embedded in kernel. > > Note that mine is a proof-of-concept prototype, however in my ad-hoc > testing its output was about a third the size of the output of the > current JIT. A simpler JIT loses a lot through not being able to do > even simple optimisations such as common subexpression elimination > and through a very primitive register allocator. > > The extra cost comes in the form of more CPU cycles spent actually > running the optimisation. JIT compilation is always a trade: is the > result being run enough times to offset the time spent optimising. > I'd have thought this would be obvious for something that is run on > every packet. Even a very slow optimiser will be a net win after a > while. More importantly, the optimisation happens at the time the > rules are loaded and so can run at a much lower priority, whereas the > packet filter evaluation happens on the critical path for network > traffic and impacts the latency of every single packet. > > David -- Aleksandr Rybalko