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

[Michael S. Tsirkin]

On Thu, Nov 02, 2023 at 02:00:46PM +0200, Yuri Benditovich wrote:
> 
> 
> On Thu, Nov 2, 2023 at 1:26 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> 
>     On Thu, Nov 02, 2023 at 12:20:39PM +0200, Yuri Benditovich wrote:
>     >
>     >
>     > On Thu, Nov 2, 2023 at 11:33 AM Michael S. Tsirkin <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. 
> 
>     Well when we flip the default we'll need compat machinery for sure ;)
> 
> 
> Of course, on the flip or default we'll need to keep compatibility to earlier
> machine types.
> But, because in the perspective it makes sense to make the RSS is on by
> default, I do not think we need _now_ to make qemu fail to start if the ebpf
> can't be loaded.
>  

Generally if user asks for something and we can't do it, we must fail.
If we can't apply a default we need a better default.
qemu has a bug in that it can't generally distinguish between default set
automatically and same default given on command line.

-- 
MST