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