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

[Li, Liang Z]

>>>  ##
>>>  { '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 tried to follow your suggestion to implement a back-compat method to 
> reuse the 'migrate-set-capabilities' and 'query-migrate-capabilities' , I 
> found that I should change a lot of current code to make it work, and I don’t 
> know how to deal with the HMP interface.  So I add 'migrate-set-parameter' 
> and 'query-migrate-parameter' interface to reduce the migrate-tunable 
> commands, they can deal with all the 'int'  type parameter, now the ' 
> compress-threads' ' , 'decompress-threads', and 'compress-level' and be 
> set/queried with the two interfaces. 
>
>{ 'enum': 'MigrationParameter',
>  'data': ['compress-level', 'compress-threads', 'decompress-threads'] }
>
>{ 'type': 'MigrationParameterStatus',
>  'data': { 'parameter' : 'MigrationParameter', 'value' : 'int' } }
>
>   I am not sure if it's a good solution, but it's much more simple, and it 
> can minimize the change of current code. Is that OK?

Hi Eric,

    What do you think about this solution?

Liang