Yuri Benditovich <yuri.benditov...@daynix.com> writes: > On Mon, Aug 30, 2021 at 9:10 AM Markus Armbruster <arm...@redhat.com> wrote: >> >> Yuri Benditovich <yuri.benditov...@daynix.com> writes: >> >> > On Tue, Aug 24, 2021 at 9:41 AM Markus Armbruster <arm...@redhat.com> >> > wrote: >> >> >> >> Andrew Melnichenko <and...@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.
