On Fri, Nov 23, 2018 at 07:55:00PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
> 
> The series brings threads to qcow2 encryption/decryption path,
> like it is already done for compression.
> 
> Based-on: Kevin's block-next branch [d3db1496c5]
> 
> Performance gain is illustrated by the following test:
> 
> ]# cat test.sh 
> #!/bin/bash
> 
> size=1G
> src=/ssd/src.raw
> dst=/ssd/dst.enc.qcow2
> 
> echo create source for tests
> ./qemu-img create -f raw "$src" $size
> ./qemu-io -f raw -c "write -P 0xa 0 $size" "$src"
> 
> for w in "" "-W"; do
>     echo -e "\n\nTest with additional paramter for qemu-img: '$w'\n"
> 
>     echo create target...
>     ./qemu-img create -f qcow2 --object secret,id=sec0,data=test -o 
> encrypt.format=luks,encrypt.key-secret=sec0,encrypt.iter-time=10 "$dst" $size
>     echo
> 
>     echo test...
>     time ./qemu-img convert $w -f raw --object secret,id=sec0,data=test 
> --target-image-opts -n "$src" 
> "driver=qcow2,file.filename=$dst,encrypt.key-secret=sec0"
> done

Note that using  iter-time=10 is removing the time penalty for opening
the luks device. This is why you didn't see the significant negative
performance impact of creating many  QCryptoBlock instances, one for
each thread.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Reply via email to