qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 2/9] migration: Add announce parameters


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [PATCH v2 2/9] migration: Add announce parameters
Date: Wed, 30 Jan 2019 10:59:10 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

On Wed, Jan 30, 2019 at 10:54:04AM +0000, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (address@hidden) wrote:
> > On Wed, Jan 30, 2019 at 10:32:29AM +0000, Dr. David Alan Gilbert (git) 
> > wrote:
> > > From: "Dr. David Alan Gilbert" <address@hidden>
> > > 
> > > Add migration parameters that control RARP/GARP announcement timeouts.
> > > 
> > > Based on earlier patches by myself and
> > >   Vladislav Yasevich <address@hidden>
> > > 
> > > Signed-off-by: Dr. David Alan Gilbert <address@hidden>
> > > ---
> > >  hmp.c                    |  28 +++++++++++
> > >  include/migration/misc.h |   2 +
> > >  include/qemu/typedefs.h  |   1 +
> > >  migration/migration.c    | 100 +++++++++++++++++++++++++++++++++++++++
> > >  qapi/migration.json      |  54 +++++++++++++++++++--
> > >  5 files changed, 182 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/qapi/migration.json b/qapi/migration.json
> > > index 7a795ecc16..113bb5d925 100644
> > > --- a/qapi/migration.json
> > > +++ b/qapi/migration.json
> > > @@ -6,6 +6,7 @@
> > >  ##
> > >  
> > >  { 'include': 'common.json' }
> > > +{ 'include': 'net.json' }
> > 
> > 
> > > @@ -572,6 +588,18 @@
> > >  ##
> > >  # @MigrateSetParameters:
> > >  #
> > > +# @announce-initial: Initial delay (in ms) before sending the first 
> > > announce
> > > +#          (Since 4.0)
> > > +#
> > > +# @announce-max: Maximum delay (in ms) between packets in the announcment
> > > +#          (Since 4.0)
> > > +#
> > > +# @announce-rounds: Number of self-announce packets sent after migration
> > > +#          (Since 4.0)
> > > +#
> > > +# @announce-step: Increase in delay (in ms) between subsequent packets in
> > > +#          the announcement (Since 4.0)
> > > +#
> > >  # @compress-level: compression level
> > >  #
> > >  # @compress-threads: compression thread count
> > > @@ -653,7 +681,11 @@
> > >  # TODO either fuse back into MigrationParameters, or make
> > >  # MigrationParameters members mandatory
> > >  { 'struct': 'MigrateSetParameters',
> > > -  'data': { '*compress-level': 'int',
> > > +  'data': { '*announce-initial': 'size',
> > > +            '*announce-max': 'size',
> > > +            '*announce-rounds': 'size',
> > > +            '*announce-step': 'size',
> > > +            '*compress-level': 'int',
> > >              '*compress-threads': 'int',
> > >              '*compress-wait-thread': 'bool',
> > >              '*decompress-threads': 'int',
> > 
> > Historically we've just had a flat list of migration parameters, but
> > QAPI doesn't require this. So I wonder about just referencing the
> > type you defined in the previous patch:
> > 
> >    '*announce': 'AnnounceParameters
> > 
> > from a QMP pov this is trivial & feels more natural. The only downside
> > I see is that for HMP it would need to be flattened to what it is here.
> > We generally tend to prefer QMP's natural style, even if it doesn't
> > match what's nicest for HMP.
> 
> I don't trust that's true from QMP; the logic to keep the parameters
> optional so that you can set a parameter individually is already pretty
> hairy.

Yes, this different design would mean that the overall 'announce' parmaeter
was optional. If you did provide one of the parameters though, you would
need to provide all 4 of them. I don't think that's a bad thing though, as
the values really only make sense when considered as a whole. So setting
one announce parameter without knowing what the other values are is somewhat
unreliable. 


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 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]