[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PULL 07/20] virtio-net: Do not propagate ebpf-rss-fds errors
From: |
Daniel P . Berrangé |
Subject: |
Re: [PULL 07/20] virtio-net: Do not propagate ebpf-rss-fds errors |
Date: |
Thu, 6 Jun 2024 08:59:10 +0100 |
User-agent: |
Mutt/2.2.12 (2023-09-09) |
On Thu, Jun 06, 2024 at 04:19:11PM +0900, Akihiko Odaki wrote:
> On 2024/06/06 16:14, Daniel P. Berrangé wrote:
> > On Thu, Jun 06, 2024 at 05:14:20AM +0900, Akihiko Odaki wrote:
> > > On 2024/06/05 19:23, Daniel P. Berrangé wrote:
> > > > On Tue, Jun 04, 2024 at 03:37:42PM +0800, Jason Wang wrote:
> > > > > From: Akihiko Odaki <akihiko.odaki@daynix.com>
> > > > >
> > > > > Propagating ebpf-rss-fds errors has several problems.
> > > > >
> > > > > First, it makes device realization fail and disables the fallback to
> > > > > the
> > > > > conventional eBPF loading.
> > > >
> > > > AFAICT, this is not a bug - this is desired behaviour.
> > > >
> > > > If the user/mgmt app has told QEMU to use FDs it has passed
> > > > in, then any failure to do this *MUST* be treated as a fatal
> > > > error. Falling back to other codepaths is ignoring a direct
> > > > user request.
> > >
> > > The FD options are more like an assistance rather than a request. When
> > > QEMU
> > > does not have a permission to load eBPF programs, a user can get the eBPF
> > > programs with the request-ebpf command of QMP, load it, and pass the FDs
> > > to
> > > QEMU.
> >
> > That still doesn't alter the fact that if the user has chosen to pass FDs
> > and QEMU fails to use them, it *MUST* report that error back to the user.
>
> The user should be more interested in whether the eBPF functionality is
> successfully enabled or not, and that is irrelevant from whether the eBPF
> program is loaded by QEMU or someone else.
No, this is wrong. A mgmt application or user will have made a decision
about *how* it wants QEMU to configure a particular feature. QEMU must
always honour the mgmt application's request, and not try to do something
different.
If the mgmt app did not want the FDs to be used, it would not have
passed them to QEMU in the first place. Ignoring the FDs is not likely
to work, because QEMU is unlikely to have permission to open the FDs
itself.
Ignoring the errors when creating the FDs, makes it much much harder
to detect and diagnose deployment problems, because the root cause
error is being discarded, and replaced by a later error which misleads
the app managing QEMU.
Always honouring the user requested config, or giving an error back
when it fails, is standard QEMU practice.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
- [PULL 01/20] tap: Remove tap_probe_vnet_hdr_len(), (continued)
- [PULL 01/20] tap: Remove tap_probe_vnet_hdr_len(), Jason Wang, 2024/06/04
- [PULL 03/20] net: Move virtio-net header length assertion, Jason Wang, 2024/06/04
- [PULL 04/20] net: Remove receive_raw(), Jason Wang, 2024/06/04
- [PULL 05/20] tap: Call tap_receive_iov() from tap_receive(), Jason Wang, 2024/06/04
- [PULL 06/20] tap: Shrink zeroed virtio-net header, Jason Wang, 2024/06/04
- [PULL 07/20] virtio-net: Do not propagate ebpf-rss-fds errors, Jason Wang, 2024/06/04
[PULL 08/20] virtio-net: Add only one queue pair when realizing, Jason Wang, 2024/06/04
[PULL 09/20] virtio-net: Copy header only when necessary, Jason Wang, 2024/06/04
[PULL 10/20] virtio-net: Shrink header byte swapping buffer, Jason Wang, 2024/06/04
[PULL 12/20] virtio-net: Unify the logic to update NIC state for RSS, Jason Wang, 2024/06/04
[PULL 11/20] virtio-net: Disable RSS on reset, Jason Wang, 2024/06/04
[PULL 13/20] virtio-net: Always set populate_hash, Jason Wang, 2024/06/04
[PULL 14/20] virtio-net: Do not write hashes to peer buffer, Jason Wang, 2024/06/04
[PULL 15/20] ebpf: Fix RSS error handling, Jason Wang, 2024/06/04
[PULL 16/20] ebpf: Return 0 when configuration fails, Jason Wang, 2024/06/04