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

[Eric Blake]

On 11/23/2014 07:25 PM, Li, Liang Z wrote:
>>>  # @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:

[please configure your mailer to wrap long lines]

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

HMP back-compat is NOT a problem we need to worry about; it's okay to
break the semantics if something else is easier to represent; it is only
QMP where we have to remain backwards compatible.  We already have
set-migrate-capability, so that seems like the command to extend,
instead of adding a new one.  On the other hand, if it is easier for you
to add a new HMP command that maps correctly to the underlying QMP
command, then that is fine, too.  The point of my proposal is that the
QMP command can use a union to provide the correct typing as needed,
without worrying about what HMP has to do to match that.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature