On 2025/08/25 21:19, Markus Armbruster wrote:
Daniel P. Berrangé <[email protected]> writes:
On Thu, Aug 07, 2025 at 03:14:56PM +0200, Markus Armbruster wrote:
Three functions in ebpf_rss.h take an Error ** argument and return bool.
Good.
They can all fail without setting an error. Not good.
The failures without error are:
* All three stubs in ebpf_rss-stub.c always. Oversight?
Opps, yes, we really should have added error_setg() calls for diagnosis
if someone tries to use eBPF when QEMU build has it disabled.
Some stubs exist only to mollify the linker. They are not meant to be
called. They should abort(), optionally with lipstick.
Other stubs are called and should fail nicely.
Can you tell me offhand which kind these are?
* Non-stub ebpf_rss_load() when ebpf_rss_is_loaded(). Are these
reachable?
This scenario should never happen, and we should add a call like
error_setg(errp, "eBPF program is already loaded");
to report it correctly.
Is it a programming error when it happens?
I think it is a programming error if one of the user-facing features
currently exist fails because ebpf_rss_load() is called when
ebpf_rss_is_loaded().
Currently ebpf_rss_load() is only necessary when the "rss" QOM property
of virtio-net is set, and setting a QOM property is an idempotent
operation, so a user can never request to load the eBPF program for one
context twice.
Regards,
Akihiko Odaki
