From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6BEC7C432BE for ; Mon, 30 Aug 2021 16:57:13 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AA08760E90 for ; Mon, 30 Aug 2021 16:57:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AA08760E90 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=daynix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:36872 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mKkat-00059R-IB for qemu-devel@archiver.kernel.org; Mon, 30 Aug 2021 12:57:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52764) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mKka3-0004Og-D6 for qemu-devel@nongnu.org; Mon, 30 Aug 2021 12:56:19 -0400 Received: from mail-ot1-x32e.google.com ([2607:f8b0:4864:20::32e]:38730) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mKka1-0006Hc-D6 for qemu-devel@nongnu.org; Mon, 30 Aug 2021 12:56:19 -0400 Received: by mail-ot1-x32e.google.com with SMTP id i8-20020a056830402800b0051afc3e373aso19237607ots.5 for ; Mon, 30 Aug 2021 09:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daynix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+dCCdDV4BPZdyGCItByPUoT49rYjWC3LEpTdddrbEQo=; b=gJgUAnt05QVp1Ph7dDaqfiIpWMCLIa19o0ULea9B0zMeJho5m1uxArChp0GZWzLdGd xBqaAddsTDlb7NJnX66AFN3rV8roIQfDw48T4hqijigqQsFXS9YZcJX1fj6deUlsk7Oe /SyqCq6Wm+9Sy8gShmb7H+p2eZIi4qdRH6HyMqSMEE0ml3ReOQIuOy87GH0D8wH02X8Q hLAUoURxbgtQpayKKTZigyei2ONgsgqWUSUtrCXwk2shJvFhgXDtGjWwAJtikpX6K0S3 KsMK6y0odyuYKYUthsUT7AQ2OFCGukuzgtMmpEeeHVIi6iOqLeIgynP9YqiJ9GAYP7YF zuJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+dCCdDV4BPZdyGCItByPUoT49rYjWC3LEpTdddrbEQo=; b=f6TKQ4Rl5vH090Nqvth6+S9dNy6p6oogjou8w+88lSzkZqiRam8pp5EXWqNP44R9zY SuoohFntHNSCYyZSYygjGMNiaUTKdWbNYcAi5OtULrMTcV+9ltx2GqYhPN6NYj1NVXnu O/xlmrMG3uW5z7MWAKUp3qE6KHYrRFzQQOh9Eyvw2s9cMuvDNEaNVgzdLGwRqDYcO2KX loqJtGAVQ3OMHbBZR12HB7L+034wIT+eN10hWj6q90is+NpGvDSoAmYQFa6QAhwJlgFt OdGsSMTgXOYBG/3JcoZf+T3v3IL4T1ixgvckUDl11OMoXcdDKz9BEdaw1iFOjYDbj9T4 EHjw== X-Gm-Message-State: AOAM530IUWCQFC6l8RF8Av1eQ6hNkcrEgd5EDxYKkl2aQung/fAue2R2 Tu7sNCyN1DRtGF2Wj1QarwPeG4na/P/lleRNv8na3Q== X-Google-Smtp-Source: ABdhPJyB2z5sOVmE9qCQZzvyumGfwoV7OdSwzBxYqKMmK/UnCgwr/JEfcH4dlBA9RVZVrDecaBQL5oZkd17OpLQU5nI= X-Received: by 2002:a05:6830:1009:: with SMTP id a9mr21302752otp.220.1630342575889; Mon, 30 Aug 2021 09:56:15 -0700 (PDT) MIME-Version: 1.0 References: <20210713153758.323614-1-andrew@daynix.com> <20210713153758.323614-6-andrew@daynix.com> <87y29dct4m.fsf@dusky.pond.sub.org> <877dgbpco1.fsf@dusky.pond.sub.org> <87v93n8nu3.fsf@dusky.pond.sub.org> <87a6kz8i4g.fsf@dusky.pond.sub.org> In-Reply-To: <87a6kz8i4g.fsf@dusky.pond.sub.org> From: Yuri Benditovich Date: Mon, 30 Aug 2021 19:56:03 +0300 Message-ID: Subject: Re: [PATCH 5/5] qmp: Added qemu-ebpf-rss-path command. To: Markus Armbruster Content-Type: text/plain; charset="UTF-8" Received-SPF: none client-ip=2607:f8b0:4864:20::32e; envelope-from=yuri.benditovich@daynix.com; helo=mail-ot1-x32e.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrew Melnichenko , =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , "Michael S. Tsirkin" , Jason Wang , qemu-devel@nongnu.org, Yan Vugenfirer , Eric Blake Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Mon, Aug 30, 2021 at 11:14 AM Markus Armbruster wrote: > > Yuri Benditovich writes: > > > On Mon, Aug 30, 2021 at 9:10 AM Markus Armbruster wrote: > >> > >> Yuri Benditovich writes: > >> > >> > On Tue, Aug 24, 2021 at 9:41 AM Markus Armbruster wrote: > >> >> > >> >> Andrew Melnichenko 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? The stamp is a string (common for qemu executable and RSS helper executable during build) that qemu can later retrieve from the helper in run-time and ensure this helper is fully compatible with this build of qemu (in terms of eBPF operation). The helper is built with the same C headers (related to ebpf operation) as the qemu, the qemu is able to receive file descriptors created by the helper (of ebpf program and ebpf data structure's maps) from libvirt and deal with them as if it has created them. > > > > >> > >> >> >> > >> >> > 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. >