[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 00/52] migration/rdma: Error handling fixes
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH 00/52] migration/rdma: Error handling fixes |
Date: |
Tue, 19 Sep 2023 19:29:32 +0100 |
User-agent: |
Mutt/2.2.9 (2022-11-12) |
On Tue, Sep 19, 2023 at 12:49:46PM -0400, Peter Xu wrote:
> On Mon, Sep 18, 2023 at 04:41:14PM +0200, Markus Armbruster wrote:
> > Oh dear, where to start. There's so much wrong, and in pretty obvious
> > ways. This code should never have passed review. I'm refraining from
> > saying more; see the commit messages instead.
> >
> > Issues remaining after this series include:
> >
> > * Terrible error messages
> >
> > * Some error message cascades remain
> >
> > * There is no written contract for QEMUFileHooks, and the
> > responsibility for reporting errors is unclear
>
> Even being removed.. because no one is really extending that..
>
> https://lore.kernel.org/all/20230509120700.78359-1-quintela@redhat.com/#t
One day (in another 5-10 years) I still hope we'll get to
the point where QEMUFile itself is obsolete :-) Getting
rid of QEMUFileHooks is a great step in that direction.
Me finishing a old PoC to bring buffering to QIOChannel
would be another big step.
The data rate limiting would be the biggest missing piece
to enable migration/vmstate logic to directly consume
a QIOChannel.
Eliminating QEMUFile would help to bring Error **errp
to all the vmstate codepaths.
> > * There seem to be no tests whatsoever
>
> I always see rdma as "odd fixes" stage.. for a long time. But maybe I was
> wrong.
In the MAINTAINERS file RDMA still get classified as formally
supported under the migration maintainers. I'm not convinced
that is an accurate description of its status. I tend to agree
with you that it is 'odd fixes' at the very best.
Dave Gilbert had previously speculated about whether we should
even consider deprecating it on the basis that latest non-RDMA
migration is too much better than in the past, with multifd
and zerocopy, that RDMA might not even offer a significant
enough peformance win to justify.
> Copying Zhijian for status of rdma; Zhijian, I saw that you just replied to
> the hwpoison issue. Maybe we should have one entry for rdma too, just like
> colo?
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 :|
- [PATCH 45/52] migration/rdma: Silence qemu_rdma_connect(), (continued)
- [PATCH 45/52] migration/rdma: Silence qemu_rdma_connect(), Markus Armbruster, 2023/09/18
- [PATCH 48/52] migration/rdma: Silence qemu_rdma_block_for_wrid(), Markus Armbruster, 2023/09/18
- [PATCH 49/52] migration/rdma: Silence qemu_rdma_register_and_get_keys(), Markus Armbruster, 2023/09/18
- [PATCH 52/52] migration/rdma: Fix how we show device details on open, Markus Armbruster, 2023/09/18
- Re: [PATCH 00/52] migration/rdma: Error handling fixes, Peter Xu, 2023/09/19
- Re: [PATCH 00/52] migration/rdma: Error handling fixes, Markus Armbruster, 2023/09/28