[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 6/6] virtio-net: rss: Add bpf filter

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},

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.


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]