qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v6 11/21] virtio-net: Return an error when vhost cannot enabl


From: Yuri Benditovich
Subject: Re: [PATCH v6 11/21] virtio-net: Return an error when vhost cannot enable RSS
Date: Fri, 3 Nov 2023 15:14:35 +0200



On Fri, Nov 3, 2023 at 11:55 AM Akihiko Odaki <akihiko.odaki@daynix.com> wrote:
On 2023/11/03 18:35, Yuri Benditovich wrote:
>
>
> On Thu, Nov 2, 2023 at 4:56 PM Akihiko Odaki <akihiko.odaki@daynix.com
> <mailto:akihiko.odaki@daynix.com>> wrote:
>
>     On 2023/11/02 19:20, Yuri Benditovich wrote:
>      >
>      >
>      > On Thu, Nov 2, 2023 at 11:33 AM Michael S. Tsirkin
>     <mst@redhat.com <mailto:mst@redhat.com>
>      > <mailto:mst@redhat.com <mailto:mst@redhat.com>>> 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=on the host does not suggest 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=off or peers
other than tap (e.g., user). rss=on employs in-qemu RSS, which incurs
overheads for such configurations.

So, vhost=off 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).

In the case of tap with vhost=off the RSS support does not create any performance degradation without eBPF.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]