From: Jason Wang <jasowang@redhat.com>
To: Yuri Benditovich <yuri.benditovich@daynix.com>
Cc: "Yan Vugenfirer" <yan@daynix.com>,
"Andrew Melnychenko" <andrew@daynix.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
qemu-devel@nongnu.org, "Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [RFC PATCH v3 4/6] ebpf: Added eBPF RSS loader.
Date: Mon, 25 Jan 2021 17:02:52 +0800 [thread overview]
Message-ID: <e4577775-2ca1-ee99-9ee9-687b5840d8c3@redhat.com> (raw)
In-Reply-To: <CAOEp5Odjd89aoCghFeZsuNv=G=2fJonFigm+3Whtj_zLuB2Jrg@mail.gmail.com>
On 2021/1/19 下午10:53, Yuri Benditovich wrote:
> On Fri, Jan 15, 2021 at 9:02 AM Jason Wang <jasowang@redhat.com> wrote:
>>
>> On 2021/1/15 上午5:16, Andrew Melnychenko wrote:
>>> From: Andrew <andrew@daynix.com>
>>>
>>> Added function that loads RSS eBPF program.
>>> Added stub functions for RSS eBPF loader.
>>> Added meson and configuration options.
>>>
>>> By default, eBPF feature enabled if libbpf is present in the build system.
>>> libbpf checked in configuration shell script and meson script.
>>>
>>> Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
>>> Signed-off-by: Andrew Melnychenko <andrew@daynix.com>
>>> ---
>>> configure | 33 ++++
>>> ebpf/ebpf_rss-stub.c | 40 ++++
>>> ebpf/ebpf_rss.c | 165 +++++++++++++++++
>>> ebpf/ebpf_rss.h | 44 +++++
>>> ebpf/meson.build | 1 +
>>> ebpf/rss.bpf.skeleton.h | 397 ++++++++++++++++++++++++++++++++++++++++
>>> ebpf/trace-events | 4 +
>>> ebpf/trace.h | 2 +
>>> meson.build | 13 ++
>>> 9 files changed, 699 insertions(+)
>>> create mode 100644 ebpf/ebpf_rss-stub.c
>>> create mode 100644 ebpf/ebpf_rss.c
>>> create mode 100644 ebpf/ebpf_rss.h
>>> create mode 100644 ebpf/meson.build
>>> create mode 100644 ebpf/rss.bpf.skeleton.h
>>> create mode 100644 ebpf/trace-events
>>> create mode 100644 ebpf/trace.h
>>>
>>> diff --git a/configure b/configure
>>> index 5860bdb77b..9d18e941f5 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -342,6 +342,7 @@ vhost_vsock="$default_feature"
>>> vhost_user="no"
>>> vhost_user_blk_server="auto"
>>> vhost_user_fs="$default_feature"
>>> +bpf=""
>>> kvm="auto"
>>> hax="auto"
>>> hvf="auto"
>>> @@ -1236,6 +1237,10 @@ for opt do
>>> ;;
>>> --enable-membarrier) membarrier="yes"
>>> ;;
>>> + --disable-bpf) bpf="no"
>>> + ;;
>>> + --enable-bpf) bpf="yes"
>>> + ;;
>>> --disable-blobs) blobs="false"
>>> ;;
>>> --with-pkgversion=*) pkgversion="$optarg"
>>> @@ -1845,6 +1850,7 @@ disabled with --disable-FEATURE, default is enabled if available
>>> vhost-user vhost-user backend support
>>> vhost-user-blk-server vhost-user-blk server support
>>> vhost-vdpa vhost-vdpa kernel backend support
>>> + bpf BPF kernel support
>>> spice spice
>>> rbd rados block device (rbd)
>>> libiscsi iscsi support
>>> @@ -5057,6 +5063,30 @@ else
>>> membarrier=no
>>> fi
>>>
>>> +##########################################
>>> +# check for usable bpf system call
>>> +if test "$bpf" = ""; then
>>
>> This implies the bpf is enabled by default?
> Yes, assuming libbpf-devel present and bpf system call defined.
>
> Any problem with it?
It means the configure will fail if libbpf is not installed. Consider
libbpf is not very common at current stage. I think it's better to make
it auto or disabled by default.
>
>>
>>> + have_bpf=no
>>> + if test "$linux" = "yes" -a "$bigendian" != "yes"; then
>>> + cat > $TMPC << EOF
>>> + #include <stdlib.h>
>>> + #include <bpf/libbpf.h>
>>> + int main(void) {
>>> + struct bpf_object *obj = NULL;
>>> + bpf_object__load(obj);
>>> + exit(0);
>>> + }
>>> +EOF
>>> + if compile_prog "" "-lbpf" ; then
>>> + have_bpf=yes
>>> + bpf=yes
>>> + fi
>>> + fi
>>> + if test "$have_bpf" = "no"; then
>>> + feature_not_found "bpf" "the libbpf is not available"
>>> + fi
>>> +fi
>>> +
>>> ##########################################
>>> # check if rtnetlink.h exists and is useful
>>> have_rtnetlink=no
>>> @@ -5905,6 +5935,9 @@ fi
>>> if test "$membarrier" = "yes" ; then
>>> echo "CONFIG_MEMBARRIER=y" >> $config_host_mak
>>> fi
>>> +if test "$bpf" = "yes" -a "$bigendian" != "yes" -a "$linux" = "yes" ; then
>>> + echo "CONFIG_EBPF=y" >> $config_host_mak
>>> +fi
>>> if test "$signalfd" = "yes" ; then
>>> echo "CONFIG_SIGNALFD=y" >> $config_host_mak
>>> fi
>>> diff --git a/ebpf/ebpf_rss-stub.c b/ebpf/ebpf_rss-stub.c
>>> new file mode 100644
>>> index 0000000000..e71e229190
>>> --- /dev/null
>>> +++ b/ebpf/ebpf_rss-stub.c
>>> @@ -0,0 +1,40 @@
>>> +/*
>>> + * eBPF RSS stub file
>>> + *
>>> + * Developed by Daynix Computing LTD (http://www.daynix.com)
>>> + *
>>> + * Authors:
>>> + * Yuri Benditovich <yuri.benditovich@daynix.com>
>>> + *
>>> + * This work is licensed under the terms of the GNU GPL, version 2. See
>>> + * the COPYING file in the top-level directory.
>>> + */
>>> +
>>> +#include "qemu/osdep.h"
>>> +#include "ebpf/ebpf_rss.h"
>>
>> I wonder why not simply use #ifdef #else to exclude the rss functions.
> Just to make the reading easier.
>
>> If I read code correctly, this stub requires rss_is_loaded called before
>> ebpf_rss_set_all(), so actually ebpf_rss_is_loaded serve the same as
> Can you please get into details?
> I think the stub does not require it, it just converts all the
> ebpf_rss calls to nop at link time.
> If I miss something please let us know, we'll fix it in v4.
I mean the current can not be used without checking rss_is_loaded(). So
rss_is_loaded() is somehow a guard like macro.
I personally prefer #ifdef but it's not a must.
Thanks
next prev parent reply other threads:[~2021-01-25 9:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-14 21:16 [RFC PATCH v3 0/6] eBPF RSS support for virtio-net Andrew Melnychenko
2021-01-14 20:54 ` no-reply
2021-01-14 21:16 ` [RFC PATCH v3 1/6] net/tap: Added TUNSETSTEERINGEBPF code Andrew Melnychenko
2021-01-14 21:16 ` [RFC PATCH v3 2/6] net: Added SetSteeringEBPF method for NetClientState Andrew Melnychenko
2021-01-14 21:16 ` [RFC PATCH v3 3/6] ebpf: Added eBPF RSS program Andrew Melnychenko
2021-01-14 21:16 ` [RFC PATCH v3 4/6] ebpf: Added eBPF RSS loader Andrew Melnychenko
2021-01-15 7:02 ` Jason Wang
2021-01-19 14:53 ` Yuri Benditovich
2021-01-25 9:02 ` Jason Wang [this message]
2021-01-25 10:52 ` Yuri Benditovich
2021-01-14 21:16 ` [RFC PATCH v3 5/6] virtio-net: Added eBPF RSS to virtio-net Andrew Melnychenko
2021-01-15 7:20 ` Jason Wang
2021-01-17 9:04 ` Yuri Benditovich
2021-01-18 3:16 ` Jason Wang
2021-01-24 8:24 ` Yuri Benditovich
2021-01-24 11:33 ` Yuri Benditovich
2021-01-25 8:59 ` Jason Wang
2021-01-14 21:16 ` [RFC PATCH v3 6/6] docs: Added eBPF documentation Andrew Melnychenko
2021-01-15 7:24 ` Jason Wang
2021-01-15 7:27 ` [RFC PATCH v3 0/6] eBPF RSS support for virtio-net Jason Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e4577775-2ca1-ee99-9ee9-687b5840d8c3@redhat.com \
--to=jasowang@redhat.com \
--cc=andrew@daynix.com \
--cc=berrange@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yan@daynix.com \
--cc=yuri.benditovich@daynix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).