|
From: | Jason Wang |
Subject: | Re: [Qemu-devel] [RFC 6/6] virtio-net: rss: Add bpf filter |
Date: | Thu, 6 Sep 2018 13:26:01 +0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
On 2018年09月04日 16:14, Daniel P. Berrangé wrote:
On Tue, Sep 04, 2018 at 11:07:38AM +0800, Jason Wang wrote:On 2018年09月03日 19:54, Daniel P. Berrangé wrote:+ * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + * + */ + +#include <linux/bpf.h> + +#ifndef BPF_RSS_INSNS +#define BPF_RSS_INSNS + +/* bpf_insn array matching l3_l4 section. see tap_bpf_program.c file */ +struct bpf_insn l3_l4_hash_insns[] = { +{0xbf , 0x6 , 0x1 , 0x0000 , 0x00000000}, +{0x28 , 0x0 , 0x0 , 0x0000 , 0x0000000c}, +{0xbf , 0x8 , 0x0 , 0x0000 , 0x00000000},[snip]+};This massive array is presumably an auto-generated content. We shouldn't be storing this in GIT. We need to store the original preferred source format, and providing makefile rules to generate it.This is possible. But it depends on eBPF toolchain (e.g recent version of LLVM) to work which is inflexible or impossible to make it work on some distributions. Providing compiled bytecode does not have such limitation.Those distros can fix their toolchain if they wish to have the BPF feature enabled when building QEMU, just like they would for any other dependancy that is needed by QEMU. Regards,
Well, since bytecode is architecture independent, it needs either emulator or JIT to work. So having eBPF toolchain looks unnecessary since we're sure it will generate exactly the same bytecodes everywhere. I think we can just treat it like some kind of virtio-net firmware and ship with bytecodes.
Thanks
[Prev in Thread] | Current Thread | [Next in Thread] |