Re: [Qemu-devel] [v2 2/2] migration: Implement multiple compression threads

[Li, Liang Z]

> >  # @auto-converge: If enabled, QEMU will automatically throttle down the 
> > guest
> >  #          to speed up convergence of RAM migration. (since 1.6)
> >  #
> >  # Since: 1.2
> >  ##
> >  { 'enum': 'MigrationCapability',
> > -  'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks'] 
> > }
> > +  'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks', 
> > + 'compress'] }
> >  

> I'll repeat what I said on v1 (but this time, with some links to back it up :)

> We really need to avoid a proliferation of new commands, two per tunable does 
> not scale well.  I think now is the time to implement my earlier suggestion 
> at making MigrationCapability become THE resource for > tunables:

> https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg02274.html

Hi, Eric

       I have read your proposal, and I just want to verify if I got it  
exactly.  Take the 'compresss-level' parameter for example, according to you 
suggestion, should I implement a command 'set-migrate-capability compress-level 
1', or  'set-migrate-parameter  compress-level 1' ?  if it's the former, how to 
keep the HMP back compatibility, as you know, the current HMP framework will 
check the parameter type, the 'int' will be processed differently from 'bool', 
;  if it's the latter,  it seems like a ' query-migrate-paramer ' command 
should be provided to keep consistency, not query-migrate-capability.

Liang