| Message ID | 20230714022358.2438995-6-andrew@daynix.com |
|---|---|
| State | New |
| Headers | show |
| Series | eBPF RSS through QMP support. | expand |
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' }
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' } + 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' }
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 QEMU build. 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. 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. 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