Messages in this thread |  | | Date | Fri, 14 Feb 2014 18:27:05 +0100 | From | Daniel Borkmann <> | Subject | Re: [RFC PATCH v2 tip 0/7] 64-bit BPF insn set and tracing filters |
| |
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 >
|  |