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

[Daniel P . Berrangé]

On Wed, Jan 30, 2019 at 12:01:46PM +0000, Dr. David Alan Gilbert wrote:
> * 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'.

Ok, well don't consider my suggestion a blocker if you think it is not
desirable.

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