From: Markus Armbruster <armbru@redhat.com>
To: Andrew Melnychenko <andrew@daynix.com>
Cc: jasowang@redhat.com, mst@redhat.com, eblake@redhat.com,
qemu-devel@nongnu.org, berrange@redhat.com,
yuri.benditovich@daynix.com, yan@daynix.com
Subject: Re: [PATCH v3 5/6] qmp: Added new command to retrieve eBPF blob.
Date: Fri, 07 Jul 2023 13:45:11 +0200 [thread overview]
Message-ID: <87edlkj67s.fsf@pond.sub.org> (raw)
In-Reply-To: <20230614221026.56950-6-andrew@daynix.com> (Andrew Melnychenko's message of "Thu, 15 Jun 2023 01:10:25 +0300")
Andrew Melnychenko <andrew@daynix.com> writes:
> Added command "request-ebpf". This command returns
> eBPF program encoded base64. The program taken from the
> skeleton and essentially is an ELF object that can be
> loaded in the future with libbpf.
>
> Signed-off-by: Andrew Melnychenko <andrew@daynix.com>
In review of v2, I asked why we need to provide eBPF programs via QMP,
and not simply via the filesystem, like all the other build artifacts.
Daniel explained
Fetching it from QEMU gives us a strong guarantee that the eBPF
code actually matches the QEMU binary we're talking to, which is
useful if you're dealing with RPMs which can be upgraded behind
your back, or have multiple parallel installs of QEMU.
I asked to work this rationale into the QAPI schema doc comments and the
commit message.
Only the doc comments are updated in this version. Please update the
commit message as well.
I remain unconvinced this justifies adding an entirely new transport.
If we want to guard against mismatch, we can do it the usual way: bake
the version into the build artifacts that must match, then check they
do.
Since I feel vetoing the change would overstep my authority as a QAPI
maintainer, I'm asking you to treat my objection as advice.
If you you elect not to follow my advice, I want you to describe the
path not chosen in the commit message. I.e. briefly explain the need
for an exact version match, describe the ways to ensure it we
considered, and the reasons for your pick.
> ---
> qapi/ebpf.json | 55 +++++++++++++++++++++++++++++++++++++++++++
> qapi/meson.build | 1 +
> qapi/qapi-schema.json | 1 +
> 3 files changed, 57 insertions(+)
> create mode 100644 qapi/ebpf.json
>
> diff --git a/qapi/ebpf.json b/qapi/ebpf.json
> new file mode 100644
> index 00000000000..6f9a1f1a0c9
> --- /dev/null
> +++ b/qapi/ebpf.json
> @@ -0,0 +1,55 @@
> +# -*- Mode: Python -*-
> +# vim: filetype=python
> +#
> +# This work is licensed under the terms of the GNU GPL, version 2 or later.
> +# See the COPYING file in the top-level directory.
> +
> +##
> +# = Machines
Copy-pasta :)
> +##
> +
> +{ 'include': 'common.json' }
> +
> +##
> +# @EbpfObject:
> +#
> +# Structure that holds eBPF ELF object encoded in base64.
> +#
> +# Since: 8.1
> +#
> +##
> +{ 'struct': 'EbpfObject',
> + 'data': {'object': 'str'} }
> +
> +##
> +# @EbpfProgramID:
> +#
> +# An enumeration of the eBPF programs. Currently, only RSS is presented.
> +# RSS - Receive side scaling, technology that allows steering traffic
> +# between queues by calculation hash. Users may set up indirection table
> +# and hash/packet types configurations. Used with virtio-net.
Let's stick to the common way to document enum members, like this:
# The eBPF programs that can be gotten with request-ebpf.
#
# @rss: ...
> +#
> +# Since: 8.1
> +##
> +{ 'enum': 'EbpfProgramID',
> + 'data': [ { 'name': 'rss', 'if': 'CONFIG_EBPF' } ] }
Uh, this makes just the member @rss conditional on CONFIG_EBPF.
Why not the entire enum?
> +
> +##
> +# @request-ebpf:
> +#
> +# Returns eBPF object that can be loaded with libbpf.
> +# Management applications (g.e. libvirt) may load it and pass file
> +# descriptors to QEMU. Which allows running QEMU without BPF capabilities.
> +# It's crucial that eBPF program/map is compatible with QEMU, so it's
> +# provided through QMP.
> +#
> +# Returns: RSS eBPF object encoded in base64.
> +#
> +# Since: 8.1
> +#
> +##
> +{ 'command': 'request-ebpf',
> + 'data': { 'id': 'EbpfProgramID' },
> + 'returns': 'EbpfObject',
> + 'if': 'CONFIG_EBPF' }
> +
> diff --git a/qapi/meson.build b/qapi/meson.build
> index 9fd480c4d81..12a1cb1f9c2 100644
> --- a/qapi/meson.build
> +++ b/qapi/meson.build
> @@ -52,6 +52,7 @@ qapi_all_modules = [
> 'transaction',
> 'virtio',
> 'yank',
> + 'ebpf',
Keep this list alphabetically sorted, please.
> ]
> if have_system
> qapi_all_modules += [
> diff --git a/qapi/qapi-schema.json b/qapi/qapi-schema.json
> index 6594afba312..169cfe8d386 100644
> --- a/qapi/qapi-schema.json
> +++ b/qapi/qapi-schema.json
> @@ -79,3 +79,4 @@
> { 'include': 'virtio.json' }
> { 'include': 'cryptodev.json' }
> { 'include': 'cxl.json' }
> +{ 'include': 'ebpf.json' }
This puts it at the end of the QMP reference manual. Is this the best
spot?
next prev parent reply other threads:[~2023-07-07 11:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-14 22:10 [PATCH v3 0/6] eBPF RSS through QMP support Andrew Melnychenko
2023-06-14 22:10 ` [PATCH v3 1/6] ebpf: Added eBPF map update through mmap Andrew Melnychenko
2023-06-21 7:58 ` Daniel P. Berrangé
2023-06-14 22:10 ` [PATCH v3 2/6] ebpf: Added eBPF initialization by fds Andrew Melnychenko
2023-06-21 7:58 ` Daniel P. Berrangé
2023-06-14 22:10 ` [PATCH v3 3/6] virtio-net: Added property to load eBPF RSS with fds Andrew Melnychenko
2023-06-21 8:01 ` Daniel P. Berrangé
2023-06-14 22:10 ` [PATCH v3 4/6] ebpf: Added declaration/initialization routines Andrew Melnychenko
2023-06-21 8:02 ` Daniel P. Berrangé
2023-06-14 22:10 ` [PATCH v3 5/6] qmp: Added new command to retrieve eBPF blob Andrew Melnychenko
2023-06-21 8:02 ` Daniel P. Berrangé
2023-07-07 11:45 ` Markus Armbruster [this message]
2023-07-10 12:52 ` Andrew Melnichenko
2023-06-14 22:10 ` [PATCH v3 6/6] ebpf: Updated eBPF program and skeleton Andrew Melnychenko
2023-06-21 7:58 ` Daniel P. Berrangé
2023-06-30 5:06 ` [PATCH v3 0/6] eBPF RSS through QMP support Jason Wang
2023-06-30 8:04 ` Daniel P. Berrangé
2023-06-30 8:21 ` Jason Wang
2023-06-30 8:55 ` Daniel P. Berrangé
2023-06-30 12:53 ` Andrew Melnichenko
2023-06-30 6:59 ` 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=87edlkj67s.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=andrew@daynix.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=jasowang@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.