On Fri, Nov 3, 2023 at 11:55 AM Akihiko Odaki <akihiko.od...@daynix.com>
wrote:

> On 2023/11/03 18:35, Yuri Benditovich wrote:
> >
> >
> > On Thu, Nov 2, 2023 at 4:56 PM Akihiko Odaki <akihiko.od...@daynix.com
> > <mailto:akihiko.od...@daynix.com>> wrote:
> >
> >     On 2023/11/02 19:20, Yuri Benditovich wrote:
> >      >
> >      >
> >      > On Thu, Nov 2, 2023 at 11:33 AM Michael S. Tsirkin
> >     <m...@redhat.com <mailto:m...@redhat.com>
> >      > <mailto:m...@redhat.com <mailto:m...@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