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: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH v2 2/9] migration: Add announce parameters
Date: Wed, 30 Jan 2019 12:01:46 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

* Daniel P. Berrangé (address@hidden) wrote:
> 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. 

Actually, some of them make a lot of sense; for example just setting
'rounds' to 0 to stop any announce works really well, or doubling it if
you want to keep it shouting longer;  my suspicion is that very few
people would fiddle with anything except 'rounds'.

Dave

> 
> 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 :|
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

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