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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]