qemu-devel
[Top][All Lists]
Advanced

[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: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [RFC 6/6] virtio-net: rss: Add bpf filter
Date: Thu, 4 Oct 2018 14:30:27 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

On Thu, Sep 06, 2018 at 01:26:01PM +0800, Jason Wang wrote:
> 
> 
> 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.

I don't find this rational very compelling. Lots of our generated files
are architecture independant and so would have the same output everywhere.
We still aim to generate them all at build from the master source using
the relevant toolchain(s).

The main exception where we bundle pre-generated stuff is the various
architecture dependant ROMs, since those need many cross-compilers.
Most of the distro vendors will drop these pre-built ROMs and build
them from source again for license compliance purposes. 

So I still believe we should be building BPF code from the master
source, not bundling any pre-generated content.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

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