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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 06433C4332F for ; Mon, 13 Nov 2023 11:44:46 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r2VMk-0006Nj-9r; Mon, 13 Nov 2023 06:44:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r2VMi-0006NE-Hr for qemu-devel@nongnu.org; Mon, 13 Nov 2023 06:44:28 -0500 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r2VMf-0007qO-HH for qemu-devel@nongnu.org; Mon, 13 Nov 2023 06:44:28 -0500 Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2c6b30aca06so56731341fa.3 for ; Mon, 13 Nov 2023 03:44:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daynix-com.20230601.gappssmtp.com; s=20230601; t=1699875863; x=1700480663; darn=nongnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8MeBVPbi402xlNda1qfnUGIhRj5mgiH8tjcgPDtZtzM=; b=yfhPWKeN/bQk7Hmb08KbBfSfyj0LiFMuvRnfAq24S3hOjcBMnt0MWUYzZGKv9FCNRu Glp6NEMu2soysUHsFU+Uc+t8alc1mPbrkgzKddqZfPMc6wRnE5LASZHnQ+ABtsTk0JOm QeeCeXI01DCnXkX0hUcL99kpn1kl7fB4njfVaReeKHWIk/MQLLk9urPi68luyP2VCt2h z6ulqluwVxZzj70obK1U4nlNKxsiXPkdoZ0vCp9IxDHmOtH/DD8KqCSGVz0B4OO0xX1N 6CJDryPMtYf6kh4fT4rbup6xSPBg2q3CulDeWNJ9fiLhwFQbbSC+042alPzPYKUJKRck htgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699875863; x=1700480663; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8MeBVPbi402xlNda1qfnUGIhRj5mgiH8tjcgPDtZtzM=; b=wUA2fIPK63fGhZ2KNP247XNexYnBffql00e7clPlpQu4HwVDPXL+/zALefvzcInk1E RHubMy6XXQvWGtoZkBqAzUF4PaxUFnc6BMivX/H1YsGg9IM63sZKu+YP96zudZt22qit P0Q7e9qbW9/wxJwrgXqKJrSjPvYr1DABeJZhZI1k9gB1wGOCWi5DrXqWHc9Y7JSEdpX+ KYpQvjQy6kiro8RvV5KRNg3sTHBDW5GmZZU4rJWSZ2caEHV67DdN+rWNWSqLCWjgKoQ7 ujEzwKHDR6+TQzIu7eAuCl4nb+/5ELXu7VH/5oJrSfL6x6h/oMHZaqLuZeJCXpjRHK4x V8lQ== X-Gm-Message-State: AOJu0YyjoiT2L2Sh4yNAPlk1/mFgYbDpC/E59yfKGM3iXufGxpuL8dDp G+3X/OZuYWHWg8xq9fI23/qGXWcrkyIziicUQHTbww== X-Google-Smtp-Source: AGHT+IHOuYf4wmt6BBWcoiudOEEI/jzVu0LpyF/13/psfyOO7OVtYUfEWqYO1caewRsc0H+Q8u2ty9V6IBI0ke7lF8k= X-Received: by 2002:a2e:9dda:0:b0:2c5:234c:86f2 with SMTP id x26-20020a2e9dda000000b002c5234c86f2mr4213814ljj.13.1699875862713; Mon, 13 Nov 2023 03:44:22 -0800 (PST) MIME-Version: 1.0 References: <58fb3b75-dd69-4715-a8ec-4c3df3b7e4c5@daynix.com> <8880b6f9-f556-46f7-a191-eeec0fe208b0@daynix.com> <20231101023805-mutt-send-email-mst@kernel.org> <39a02a4c-f8fa-437c-892f-caca84b8d85d@daynix.com> <20231101050838-mutt-send-email-mst@kernel.org> <20231102053202-mutt-send-email-mst@kernel.org> <2fbdee21-60f4-49ff-b61b-923c895f90ba@daynix.com> <8439be4e-a739-4cbd-a569-89b6c7f68ab9@daynix.com> In-Reply-To: <8439be4e-a739-4cbd-a569-89b6c7f68ab9@daynix.com> From: Yuri Benditovich Date: Mon, 13 Nov 2023 13:44:10 +0200 Message-ID: Subject: Re: [PATCH v6 11/21] virtio-net: Return an error when vhost cannot enable RSS To: Akihiko Odaki Cc: "Michael S. Tsirkin" , Jason Wang , qemu-devel@nongnu.org, Andrew Melnychenko Content-Type: multipart/alternative; boundary="000000000000f5a94b060a0730d5" Received-SPF: none client-ip=2a00:1450:4864:20::235; envelope-from=yuri.benditovich@daynix.com; helo=mail-lj1-x235.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org --000000000000f5a94b060a0730d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 11, 2023 at 5:28=E2=80=AFPM Akihiko Odaki wrote: > On 2023/11/03 22:14, Yuri Benditovich wrote: > > > > > > On Fri, Nov 3, 2023 at 11:55=E2=80=AFAM Akihiko Odaki > > wrote: > > > > On 2023/11/03 18:35, Yuri Benditovich wrote: > > > > > > > > > On Thu, Nov 2, 2023 at 4:56=E2=80=AFPM Akihiko Odaki > > > > > > >> wrote: > > > > > > On 2023/11/02 19:20, Yuri Benditovich wrote: > > > > > > > > > > > > On Thu, Nov 2, 2023 at 11:33=E2=80=AFAM Michael S. Tsirki= n > > > > > > > > > > > > >>> wrote: > > > > > > > > On Thu, Nov 02, 2023 at 11:09:27AM +0200, Yuri > > Benditovich wrote: > > > > > Probably we mix two different patches in this > > discussion. > > > > > Focusing on the patch in the e-mail header: > > > > > > > > > > IMO it is not acceptable to fail QEMU run for one > > feature > > > that we > > > > can't make > > > > > active when we silently drop all other features in > > such a > > > case. > > > > > > > > If the feature is off by default then it seems more > > reasonable > > > > and silent masking can be seen as a bug. > > > > Most virtio features are on by default this is why it= 's > > > > reasonable to mask them. > > > > > > > > > > > > If we are talking about RSS: setting it initially off is > the > > > development > > > > time decision. > > > > When it will be completely stable there is no reason to > > keep it > > > off by > > > > default, so this is more a question of time and of a > > readiness of > > > libvirt. > > > > > > It is not ok to make "on" the default; that will enable RSS > > even when > > > eBPF steering support is not present and can result in > > performance > > > degradation. > > > > > > > > > Exactly as it is today - with vhost=3Don the host does not sugge= st > RSS > > > without eBPF. > > > I do not understand what you call "performance degradation", can > you > > > describe the scenario? > > > > I was not clear, but I was talking about the case of vhost=3Doff or > peers > > other than tap (e.g., user). rss=3Don employs in-qemu RSS, which in= curs > > overheads for such configurations. > > > > > > So, vhost=3Doff OR peers other than tap: > > > > In the case of peers other than tap (IMO) we're not talking about > > performance at all. > > Backends like "user" (without vnet_hdr) do not support _many_ > > performance-oriented features. > > If RSS is somehow "supported" for such backends this is rather a > > misunderstanding (IMO again). > > We do not need to ensure good performance when RSS is enabled by the > guest for backends without eBPF steering program as you say. In-QEMU RSS > is only useful for testing and not meant to improve the performance. > > However, if you set rss=3Don, QEMU will advertise the availability of RSS > feature. The guest will have no mean to know if it's implemented in a > way not performance-wise so it may decide to use the feature to improve > the performance, which can result in performance degradation. Therefore, > it's better not to set rss=3Don for such backends. > I still do not understand what is the scenario where you see or suspect the mentioned "performance degradation". We can discuss whether such a problem exists as soon as you explain it. --000000000000f5a94b060a0730d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Nov 11, 2023 at 5:28=E2=80=AF= PM Akihiko Odaki <akihiko.od= aki@daynix.com> wrote:
On 2023/11/03 22:14, Yuri Benditovich wrote:
>
>
> On Fri, Nov 3, 2023 at 11:55=E2=80=AFAM Akihiko Odaki <akihiko.odaki@daynix.com<= /a>
> <mailto:akihiko.odaki@daynix.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 2023/11/03 18:35, Yuri Benditovich wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Thu, Nov 2, 2023 at 4:56=E2=80=AFPM Akihik= o Odaki
>=C2=A0 =C2=A0 =C2=A0<akihiko.odaki@daynix.com <mailto:akihiko.odaki@daynix.com><= br> >=C2=A0 =C2=A0 =C2=A0 > <mailto:akihiko.odaki@daynix.com
>=C2=A0 =C2=A0 =C2=A0<mailto:akihiko.odaki@daynix.com>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 2023/11/02 19:20, Yuri = Benditovich wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > On Thu, Nov 2, 2023 = at 11:33=E2=80=AFAM Michael S. Tsirkin
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mst@redhat.com <mailto:mst@redhat.com>
>=C2=A0 =C2=A0 =C2=A0<mailto:mst@redhat.com <mailto:mst@redhat.com>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > <mailto:mst@redhat.com <mailto:= mst@redhat.com><= br> >=C2=A0 =C2=A0 =C2=A0<mailto:mst@redhat.com <mailto:mst@redhat.com>>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0O= n Thu, Nov 02, 2023 at 11:09:27AM +0200, Yuri
>=C2=A0 =C2=A0 =C2=A0Benditovich wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > Probably we mix two different patches in this
>=C2=A0 =C2=A0 =C2=A0discussion.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > Focusing on the patch in the e-mail header:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > IMO it is not acceptable to fail QEMU run for one
>=C2=A0 =C2=A0 =C2=A0feature
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0that we
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0c= an't make
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > active when we silently drop all other features in
>=C2=A0 =C2=A0 =C2=A0such a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0case.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I= f the feature is off by default then it seems more
>=C2=A0 =C2=A0 =C2=A0reasonable
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0a= nd silent masking can be seen as a bug.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0M= ost virtio features are on by default this is why it's
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0r= easonable to mask them.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > If we are talking ab= out RSS: setting it initially off is the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0development
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > time decision.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > When it will be comp= letely stable there is no reason to
>=C2=A0 =C2=A0 =C2=A0keep it
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0off by
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > default, so this is = more a question of time and of a
>=C2=A0 =C2=A0 =C2=A0readiness of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0libvirt.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0It is not ok to make "= ;on" the default; that will enable RSS
>=C2=A0 =C2=A0 =C2=A0even when
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0eBPF steering support is n= ot present and can result in
>=C2=A0 =C2=A0 =C2=A0performance
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0degradation.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Exactly as it is today - with vhost=3Don the = host does not suggest RSS
>=C2=A0 =C2=A0 =C2=A0 > without=C2=A0 eBPF.
>=C2=A0 =C2=A0 =C2=A0 > I do not understand what you call "perfo= rmance degradation", can you
>=C2=A0 =C2=A0 =C2=A0 > describe the scenario?
>
>=C2=A0 =C2=A0 =C2=A0I was not clear, but I was talking about the case o= f vhost=3Doff or peers
>=C2=A0 =C2=A0 =C2=A0other than tap (e.g., user). rss=3Don employs in-qe= mu RSS, which incurs
>=C2=A0 =C2=A0 =C2=A0overheads for such configurations.
>
>
> So, vhost=3Doff OR peers other than tap:
>
> In the case of peers other than tap (IMO) we're not talking about =
> performance at all.
> Backends like "user" (without vnet_hdr) do not support _many= _
> performance-oriented features.
> If RSS is somehow "supported" for such backends this is rath= er a
> misunderstanding (IMO again).

We do not need to ensure good performance when RSS is enabled by the
guest for backends without eBPF steering program as you say. In-QEMU RSS is only useful for testing and not meant to improve the performance.

However, if you set rss=3Don, QEMU will advertise the availability of RSS <= br> feature. The guest will have no mean to know if it's implemented in a <= br> way not performance-wise so it may decide to use the feature to improve the performance, which can result in performance degradation. Therefore, it's better not to set rss=3Don for such backends.

I still do not understand what is the scenario where you se= e or suspect the mentioned "performance degradation".
W= e can discuss whether such a problem exists as soon as you explain it.


--000000000000f5a94b060a0730d5--