From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752608AbaBNR2J (ORCPT ); Fri, 14 Feb 2014 12:28:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2230 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752041AbaBNR2G (ORCPT ); Fri, 14 Feb 2014 12:28:06 -0500 Message-ID: <52FE51E9.8000203@redhat.com> Date: Fri, 14 Feb 2014 18:27:05 +0100 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alexei Starovoitov CC: Ingo Molnar , "David S. Miller" , Steven Rostedt , Peter Zijlstra , "H. Peter Anvin" , Thomas Gleixner , Masami Hiramatsu , Tom Zanussi , Jovi Zhangwei , Eric Dumazet , Linus Torvalds , Andrew Morton , Frederic Weisbecker , Arnaldo Carvalho de Melo , Pekka Enberg , Arjan van de Ven , Christoph Hellwig , linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [RFC PATCH v2 tip 0/7] 64-bit BPF insn set and tracing filters References: <1391649046-4383-1-git-send-email-ast@plumgrid.com> <52F3670D.5090608@redhat.com> <52FD2908.8000009@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/14/2014 05:47 AM, Alexei Starovoitov wrote: ... >> Do you see a possibility to integrate your work step by step? That is, > > Sure. let's see how we can do it. > >> to first integrate the interpreter part only; meaning, to detect "old" >> BPF programs e.g. coming from SO_ATTACH_FILTER et al and run them in >> compatibility mode while extended BPF is fully integrated and replaces >> the old engine in net/core/filter.c. Maybe, "old" programs can be > > do you mean drop bfp64_jit, checker and just have bpf32->bpf64 converter > and bpf64 interpreter as phase 1 ? > Checking is done by old bpf32, > all existing bpf32 jits, if available, can convert bpf32 to native, > but interpreter will be running on bpf64 ? > phase 2 to introduce bpf64_x86 jit and so on? > Sounds fine. If that's possible, so first step would be to migrate bpf_run() from patch1 into sk_run_filter() form net/core/filter.c, and also bring in related include file into include/linux/filter.h resp. include/uapi/linux/filter.h. Plus code that is needed to verify the image in new (and old) format e.g. bpf_load_image() et al, and to either convert old programs into the new format, for example; generally, to find a way to still handle them (bpf/seccomp) while having the new code included and leaving new JITs aside. That I think could be phase 1. Phase 2 would be to successively replace current JITs, etc. > Today I didn't try to optimize bpf64 interpreter, since insn set is designed > for eventual JITing and interpreter is there to support archs that don't > have jit yet. > I guess I have to tweak it to perform at bpf32 interpreter speeds. > >> transformed transparently to the new representation and then would be >> good to execute in eBPF. If possible, in such a way that in the first >> step JIT compilers won't need any upgrades. Once that is resolved, >> JIT compilers could successively migrate, arch by arch, to compile the >> new code? And last but not least the existing tools as well for handling >> eBPF. I think, if possible, that would be great. Also, I unfortunately >> haven't looked into your code too deeply yet due to time constraints, >> but I'm wondering e.g. for accessing some skb fields we currently use >> the "hack" to "overload" load instructions with negative arguments. Do >> we have a sort of "meta" instruction that is extendible in eBPF to avoid >> such things in future? > > Exactly. > This 'negative offset' hack of bpf32 isn't very clean, since jits for all archs > need to change when new offsets added. > For bpf64 I'm proposing a customizable 'bpf_context' and variable set > of bpf-callable functions, so JITs don't need to change and verifier > stays the same. > That's the idea behind 'bpf_callbacks' in include/linux/bpf_jit.h > > Some meta data makes sense to pass as input into bpf program. > Like for seccomp 'bpf_context' can be 'struct seccomp_data' > > For networking, bpf_context can be 'skb', > then bpf_s_anc_protocol becomes a normal 2-byte bpf64 load > from skb->protocol field. Allowing access to other fields of skb > is just a matter of defining permissions of 'struct bpf_context' in > bpf_callback->get_context_access() > > Some other meta data and extensions are cleaner when defined > as function calls from bpf, since calls are free. > I think bpf_table_lookup() is a fundamental one that allows to define > arbitrary tables within bpf and access them from the program. > (here I need feedback the most whether to access tables > via netlink from userspace or via debugfs...) > > It probably will be easier to read the code of bpf32-bpf64 converter > to understand the differences between the two. > I guess I have to start working on the converter sooner than I thought... > > Thanks > Alexei > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >