On 2023/11/03 22:14, Yuri Benditovich wrote:
>
>
> On Fri, Nov 3, 2023 at 11:55 AM Akihiko Odaki <akihiko.odaki@daynix.com
> <mailto: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>
>      > <mailto: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>>
>      >      > <mailto: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).

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=on, 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=on for such backends.