All of lore.kernel.org
 help / color / mirror / Atom feed
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 v4 5/6] qmp: Added new command to retrieve eBPF blob.
Date: Fri, 14 Jul 2023 09:41:37 +0200	[thread overview]
Message-ID: <87sf9rey8e.fsf@pond.sub.org> (raw)
In-Reply-To: <20230714022358.2438995-6-andrew@daynix.com> (Andrew Melnychenko's message of "Fri, 14 Jul 2023 05:23:57 +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.
>
> The reason to use the command to provide the eBPF object
> instead of a separate artifact was to avoid issues related
> to finding the eBPF itself. As the eBPF maps/program should
> correspond to QEMU, the eBPF cant be used from different

can't

> QEMU build.

Blank line between paragaphs.

> The first solution was a helper that comes with QEMU
> and loads appropriate eBPF objects. And the issue is
> to find a proper helper if the system has several
> different QEMUs installed and/or built from the source,
> which helpers may not be compatible.

Blank line between paragaphs.

> Another issue is QEMU updating while there is a running
> QEMU instance. With an updated helper, it may not be
> possible to hotplug virtio-net device to the already
> running QEMU. Overall, requesting the eBPF object from
> QEMU itself solves possible failures with very little effort.

I respectfully disagree with "very little".  But it's your commit
message, not mine.  "Acceptable effort"?

> Links:
> [PATCH 3/5] qmp: Added the helper stamp check.
> https://lore.kernel.org/all/20230219162100.174318-4-andrew@daynix.com/
>
> Signed-off-by: Andrew Melnychenko <andrew@daynix.com>
> ---
>  qapi/ebpf.json        | 58 +++++++++++++++++++++++++++++++++++++++++++
>  qapi/meson.build      |  1 +
>  qapi/qapi-schema.json |  1 +
>  3 files changed, 60 insertions(+)
>  create mode 100644 qapi/ebpf.json
>
> diff --git a/qapi/ebpf.json b/qapi/ebpf.json
> new file mode 100644
> index 0000000000..3237da69a7
> --- /dev/null
> +++ b/qapi/ebpf.json
> @@ -0,0 +1,58 @@
> +# -*- 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.
> +
> +##
> +# = eBPF Objects
> +##
> +
> +{ 'include': 'common.json' }
> +
> +##
> +# @EbpfObject:
> +#
> +# Structure that holds eBPF ELF object encoded in base64.
> +#
> +# Since: 8.3
> +#
> +##
> +{ 'struct': 'EbpfObject',
> +  'data': {'object': 'str'},
> +  'if': 'CONFIG_EBPF' }
> +
> +##
> +# @EbpfProgramID:
> +#
> +# The eBPF programs that can be gotten with request-ebpf.
> +#
> +# @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.
> +#
> +# Since: 8.3
> +##
> +{ 'enum': 'EbpfProgramID',
> +  'if': 'CONFIG_EBPF',
> +  'data': [ { 'name': 'rss' } ] }
> +
> +##
> +# @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.3
> +#
> +##
> +{ 'command': 'request-ebpf',
> +  'data': { 'id': 'EbpfProgramID' },
> +  'returns': 'EbpfObject',
> +  'if': 'CONFIG_EBPF' }
> +

Trim the trailing blank line.

Terminology: you use "eBPF program" and "eBPF object".  What's the
difference?  If there's none, use only one term, please.  To me,
"program" feels more clear.

> diff --git a/qapi/meson.build b/qapi/meson.build
> index 60a668b343..90047dae1c 100644
> --- a/qapi/meson.build
> +++ b/qapi/meson.build
> @@ -33,6 +33,7 @@ qapi_all_modules = [
>    'crypto',
>    'cxl',
>    'dump',
> +  'ebpf',
>    'error',
>    'introspect',
>    'job',
> diff --git a/qapi/qapi-schema.json b/qapi/qapi-schema.json
> index 6594afba31..2c82a49bae 100644
> --- a/qapi/qapi-schema.json
> +++ b/qapi/qapi-schema.json
> @@ -53,6 +53,7 @@
>  { 'include': 'char.json' }
>  { 'include': 'dump.json' }
>  { 'include': 'net.json' }
> +{ 'include': 'ebpf.json' }
>  { 'include': 'rdma.json' }
>  { 'include': 'rocker.json' }
>  { 'include': 'tpm.json' }



  reply	other threads:[~2023-07-14  7:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-14  2:23 [PATCH v4 0/6] eBPF RSS through QMP support Andrew Melnychenko
2023-07-14  2:23 ` [PATCH v4 1/6] ebpf: Added eBPF map update through mmap Andrew Melnychenko
2023-07-14  2:23 ` [PATCH v4 2/6] ebpf: Added eBPF initialization by fds Andrew Melnychenko
2023-07-14  2:23 ` [PATCH v4 3/6] virtio-net: Added property to load eBPF RSS with fds Andrew Melnychenko
2023-07-14  2:23 ` [PATCH v4 4/6] ebpf: Added declaration/initialization routines Andrew Melnychenko
2023-07-14  7:23   ` Markus Armbruster
2023-07-14  7:26   ` Markus Armbruster
2023-07-14  2:23 ` [PATCH v4 5/6] qmp: Added new command to retrieve eBPF blob Andrew Melnychenko
2023-07-14  7:41   ` Markus Armbruster [this message]
2023-07-14  2:23 ` [PATCH v4 6/6] ebpf: Updated eBPF program and skeleton Andrew Melnychenko

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=87sf9rey8e.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.