Kevin, Max, suggest to skip right to Qcow2CompressionType.

Zeyu Jin <jinz...@huawei.com> writes:

> A multi-thread compress method parameter is added to hold the method we
> are going to use. By default the 'zlib' method is used to maintain the
> compatibility as before.
>
> Signed-off-by: Zeyu Jin <jinz...@huawei.com>
> Signed-off-by: Ying Fang <fangyi...@huawei.com>
[...]
> diff --git a/qapi/migration.json b/qapi/migration.json
> index 3c75820527..2ed6a55b92 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -525,6 +525,19 @@
>    'data': [ 'none', 'zlib',
>              { 'name': 'zstd', 'if': 'defined(CONFIG_ZSTD)' } ] }
>  
> +##
> +# @CompressMethod:
> +#
> +# An enumeration of multi-thread compression methods.
> +#
> +# @zlib: use zlib compression method.
> +#
> +# Since: 6.0
> +#
> +##
> +{ 'enum': 'CompressMethod',
> +  'data': [ 'zlib' ] }
> +
>  ##
>  # @BitmapMigrationBitmapAlias:
>  #
> @@ -599,6 +612,9 @@
>  #                      compression, so set the decompress-threads to the 
> number about 1/4
>  #                      of compress-threads is adequate.
>  #
> +# @compress-method: Set compression method to use in multi-thread 
> compression.
> +#                   Defaults to zlib. (Since 6.0)

We already have @multifd-compression.  Why do we need to control the two
separately?  Can you give a use case for different settings?

If we do want two parameters: the names @compress-method and
@multifd-compression are inconsistent.  According to your comment,
@compress-method applies only to multi-thread compression.  That leads
me to suggest renaming it to @multi-thread-compression.

After PATCH 4, CompressMethod is almost the same as MultiFDCompression:

   { 'enum': 'CompressMethod',
     'data': [ 'zlib' ] }
     'data': [ 'zlib', { 'name': 'zstd', 'if': 'defined(CONFIG_ZSTD)' } ] }

   { 'enum': 'MultiFDCompression',
     'data': [ 'none', 'zlib',
               { 'name': 'zstd', 'if': 'defined(CONFIG_ZSTD)' } ] }

The difference is member 'none'.  Why does compression 'none' make sense
for multi-fd, but not for multi-thread?

If the difference is wanted: the names are inconsistent.  Less of an
issue than member names, because type names are not externally visible.
Let's make them consistent anyway.

Hmm, there's also Qcow2CompressionType.  That's another conversation;
I'll start a new thread for it.

[...]


Reply via email to