Re: [PATCH 0/2] support block encryption/decryption in parallel

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Nov 28, 2024 at 06:51:20PM +0800, tugy@chinatelecom.cn wrote:
> From: Guoyi Tu <tugy@chinatelecom.cn>
> 
> Currently, disk I/O encryption and decryption operations are performed sequentially
> in the main thread or IOthread. When the number of I/O requests increases,
> this becomes a performance bottleneck.
> 
> To address this issue, this patch use thread pool to perform I/O encryption
> and decryption in parallel, improving overall efficiency.

We already have support for parallel encryption through use of IO threads
since approximately this commit:

  commit af206c284e4c1b17cdfb0f17e898b288c0fc1751
  Author: Stefan Hajnoczi <stefanha@redhat.com>
  Date:   Mon May 27 11:58:50 2024 -0400

    block/crypto: create ciphers on demand
    
    Ciphers are pre-allocated by qcrypto_block_init_cipher() depending on
    the given number of threads. The -device
    virtio-blk-pci,iothread-vq-mapping= feature allows users to assign
    multiple IOThreads to a virtio-blk device, but the association between
    the virtio-blk device and the block driver happens after the block
    driver is already open.
    
    When the number of threads given to qcrypto_block_init_cipher() is
    smaller than the actual number of threads at runtime, the
    block->n_free_ciphers > 0 assertion in qcrypto_block_pop_cipher() can
    fail.
    
    Get rid of qcrypto_block_init_cipher() n_thread's argument and allocate
    ciphers on demand.


Say we have QEMU pinned to 4 host CPUs, and we've setup 4 IO threads
for the disk, then encryption can max out 4 host CPUs worth of resource.

How is this new proposed way to use a thread pool going to do better
than that in an apples-to-apples comparison ? ie allow same number
of host CPUs for both. The fundamental limit is still the AES performance
of the host CPU(s) that you allow QEMU to execute work on. If the thread
pool is allowed to use 4 host CPUs, it shouldn't be significantly different
from allowing use of 4 host CPUs for I/O threads surely ?

Having multiple different ways to support parallel encryption is not
ideal. If there's something I/O threads can't do optimally right
now, is it practical to make them work better ?

With 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 :|