[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 3/3] multifd: Implement zerocopy write in multifd migratio
From: |
Peter Xu |
Subject: |
Re: [PATCH v4 3/3] multifd: Implement zerocopy write in multifd migration (multifd-zerocopy) |
Date: |
Wed, 27 Oct 2021 15:06:01 +0800 |
On Wed, Oct 27, 2021 at 03:47:18AM -0300, Leonardo Bras Soares Passos wrote:
> On Wed, Oct 13, 2021 at 3:24 AM Peter Xu <peterx@redhat.com> wrote:
> >
> > On Sat, Oct 09, 2021 at 04:56:13AM -0300, Leonardo Bras wrote:
> > > diff --git a/qapi/migration.json b/qapi/migration.json
> > > index 88f07baedd..c4890cbb54 100644
> > > --- a/qapi/migration.json
> > > +++ b/qapi/migration.json
> > > @@ -724,6 +724,11 @@
> > > # will consume more CPU.
> > > # Defaults to 1. (Since 5.0)
> > > #
> > > +# @multifd-zerocopy: Controls behavior on sending memory pages on
> > > multifd migration.
> > > +# When true, enables a zerocopy mechanism for sending
> > > memory
> > > +# pages, if host does support it.
> > > +# Defaults to false. (Since 6.2)
> > > +#
> >
> > Shall we keep it named "@zerocopy"? Yes we have that dependency with
> > multifd,
> > but it's fine to just fail the configuration if multifd not set. The thing
> > is
> > we don't know whether that dependency will last forever, and we probably
> > don't
> > want to introduce yet another feature bit when we can remove the
> > dependency..
> > as we can't remove the old one to be compatible.
>
> It makes sense not wanting to create a new future bit in the future,
> but if we just add a
> "@zerocopy' , wouldn't we need to fail every migration setup that
> don't support zerocopy?
>
> (Thinking back, to stay as it is, it would also be necessary that I
> find a way to fail other multifd setups that don't support zerocopy,
> for v5)
Yes I think so; imho we can fail either whey applying the bit, or it's okay too
to fail at the start of migration. Thanks,
--
Peter Xu