Re: [PATCH 5/5] qmp: Added qemu-ebpf-rss-path command.

[Markus Armbruster]

Yuri Benditovich <yuri.benditovich@daynix.com> writes:

> On Mon, Aug 30, 2021 at 9:10 AM Markus Armbruster <armbru@redhat.com> wrote:
>>
>> Yuri Benditovich <yuri.benditovich@daynix.com> writes:
>>
>> > On Tue, Aug 24, 2021 at 9:41 AM Markus Armbruster <armbru@redhat.com> 
>> > wrote:
>> >>
>> >> Andrew Melnichenko <andrew@daynix.com> writes:
>> >>
>> >> > Hi,
>> >> >
>> >> >> The helper may or may not be installed at the path compiled into QEMU.
>> >> >>
>> >> > Yes, so the helper will not be called - QEMU will try to initiate eBPF 
>> >> > RSS
>> >> > or use "in-qemu" RSS.
>> >>
>> >> My point is: the proposed command's mission is to help the management
>> >> application run the right helper.  However, its advice is *unreliable*.
>> >> It may point to the wrong helper, or to nothing at all.  The right
>> >> helper may still exist elsewhere.
>> >
>> > Hi Markus,
>> > Indeed the intention of this command is to return the proper helper.
>> > Especially in the case of RSS helper this is *reliable* advice and it
>> > points to the helper that was built together with QEMU, i.e. with the
>> > same headers.
>> > This was discussed earlier, for example in
>> > https://lists.nongnu.org/archive/html/qemu-devel/2021-06/msg02248.html
>> >
>> >>
>> >> I suspect you're trying to address the problem at the wrong level.
>> >
>> > What is the proper solution for the problem from your point of view?
>>
>> I'll explain in more detail, but first I'd like you to answer my
>> question below.
>>
>> >> Similar versioning issues exist with other helpers.  We've been doing
>> >> fine without QEMU providing unreliable advice on where they might sit in
>> >> the file system.  What makes this one different?
>> >
>> > This one is required to be *fully synchronized* with the existing build of 
>> > QEMU.
>> > Other helpers are probably less restrictive and do not have common
>> > structures definitions with the QEMU, otherwise they would face the
>> > same problem.
>> >
>> >>
>> >> >> What happens when you use the wrong helper?
>> >
>> > Our intention is that libvirt should never use the wrong RSS helper.
>> > But it does not have any ability to check which helper is compatible
>> > with the QEMU.
>> > QEMU can easily recognize the correct one.
>>
>> You did not actually answer my question :)
>>
>> So let's try again: if libvirt does use the wrong RSS helper, how does
>> the system behave?
>
> The receive-side scaling may work incorrectly, i.e. finally may move
> incoming packets to a virtqueue different than expected one.

Then I'm confused about the purpose of "the stamp" mentioned below.  Can
you enlighten me?

>
>>
>> >> >>
>> >> > UB - in most cases, eBPF program will work with wrong configurations.
>> >> > That's why the stamp was added.
>> >> >
>> >> > query-helper-paths checks the stamp only for RSS helper.
>> >>
>> >> I have no idea what you're talking about :)
>> >>
>> >> My best guess is that you're trying to tell me that attempting to work
>> >> with the wrong helper will fail cleanly due to some stamp check.  That
>> >> would be nice.