Andrew Melnichenko <and...@daynix.com> writes:
> Hi all,
> Thanks for the comments - I'll update and send new patches.
>
> On Sat, Aug 5, 2023 at 10:34 AM Markus Armbruster <arm...@redhat.com> wrote:
>>
>> Andrew Melnychenko <and...@daynix.com> writes:
>>
>> > Now, the binary objects may be retrieved by id.
>> > It would require for future qmp commands that may require specific
>> > eBPF blob.
>> >
>> > 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. eBPF object is an ELF binary
>> > that contains the eBPF program and eBPF map description(BTF).
>> > Overall, eBPF object should contain the program and enough
>> > metadata to create/load eBPF with libbpf. As the eBPF
>> > maps/program should correspond to QEMU, the eBPF can't
>> > 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 acceptable effort.
>> >
>> > Links:
>> > [PATCH 3/5] qmp: Added the helper stamp check.
>> > https://lore.kernel.org/all/20230219162100.174318-4-and...@daynix.com/
>> >
>> > Signed-off-by: Andrew Melnychenko <and...@daynix.com>
>> > ---
>>
>> [...]
>>
>> > diff --git a/qapi/ebpf.json b/qapi/ebpf.json
>> > new file mode 100644
>> > index 00000000000..40851f8c177
>> > --- /dev/null
>> > +++ b/qapi/ebpf.json
[...]
>> > +##
>> > +# @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.
>>
>> What does "RSS" mean?
>
> RSS - Receive-side Scaling.
Suggest to use something like "receive-side scaling (RSS)" the first
time.
You could also put a general introduction right below the header, like
##
# = eBPF Objects
#
# Text goes here
##
This is not a demand.
[...]
