All of lore.kernel.org
 help / color / mirror / Atom feed
From: tugy@chinatelecom.cn
To: eblake@redhat.com, armbru@redhat.com, kwolf@redhat.com,
	hreitz@redhat.com, qemu-block@nongnu.org
Cc: qemu-devel@nongnu.org, tugy@chinatelecom.cn
Subject: [PATCH 0/2] support block encryption/decryption in parallel
Date: Thu, 28 Nov 2024 18:51:20 +0800	[thread overview]
Message-ID: <cover.1732789721.git.tugy@chinatelecom.cn> (raw)

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.

Test results show that enabling the thread pool for encryption and decryption
significantly improve the performance of virtual machine storage devices.


Test Case1: Disk read/write performance using fio in a virtual machine

Virtual Machine: 8c16g, with a disk backing by a LUKS storage device and
                  Ceph as storage backend.
Test Method:
fio -direct=1 -iodepth=32 -rw=xx -ioengine=libaio -bs=4k -size=10G -numjobs=x \
-runtime=1000 -group_reporting -filename=/dev/vdb -name=xxx

Runing the VM on the Intel Xeon 5218 server, The test results are as follows:

|                        |  Serial encryption  | Thread pool encryption|
|                        |  and decryption     | and decryption      |
|        fio             |-----------|---------|-----------|---------|
|                        | BW(MiB/s) | IOPS(K) | BW(MiB/s) | IOPS(K) |
|------------------------|-----------|---------|-----------|---------|
| rw=read numjobs=2      | 499       | 128     | 605       | 155     |
| rw=read numjobs=4      | 529       | 136     | 632       | 162     |
| rw=write numjobs=2     | 493       | 126     | 617       | 158     |
| rw=write numjobs=4     | 534       | 137     | 743       | 190     |


Runing the VM on the HiSilicon Kunpeng-920 server, The test results are as follows:

|                        |  Serial encryption  | Thread pool encryption|
|                        |  and decryption     | and decryption      |
|        fio             |-----------|---------|-----------|---------|
|                        | BW(MiB/s) | IOPS(K) | BW(MiB/s) | IOPS(K) |
|------------------------|-----------|---------|-----------|---------|
| rw=read numjobs=2      | 73.2      | 18.8    | 128       | 39.2    |
| rw=read numjobs=4      | 77.9      | 19.9    | 246       | 62.9    |
| rw=write numjobs=2     | 78        | 19      | 140       | 35.8    |
| rw=write numjobs=4     | 78        | 20.2    | 270       | 69.1    |


Test Case 2:
In addition, performance comparisons were also conducted on the HiSilicon Kunpeng-920
server, testing the conversion of a qcow2 image to a LUKS image using qemu-img convert.
The results show that using thread pool to encryption and decryption all significantly
improve the performance.

Test Method: Create a 40GB qcow2 image and fill it with data, then convert it to a LUKS
             image using qemu-img

* Serial encryption and decryption:
time qemu-img convert -p -m 16 -W --image-opts file.filename=/home/tgy/data.qcow2 \
--object secret,id=sec,data=password -n \
--target-image-opts driver=luks,key-secret=sec,file.filename=/home/tgy/data.luks

    real    7m53.681s
    user    7m52.595s
    sys     0m11.248s


* Thread pool encryption and decryption:
time qemu-img convert -p -m 16 -W --image-opts file.filename=/home/tgy/data.qcow2 \
--object secret,id=sec,data=password -n --target-image-opts \
driver=luks,key-secret=sec,encrypt-in-parallel=on,file.filename=/home/tgy/data.luks

    real    1m43.101s
    user    10m30.239s
    sys     13m13.758s

Guoyi Tu (2):
  crpyto: support encryt and decrypt parallelly using thread pool
  qapi/crypto: support enable encryption/decryption in parallel

 block/crypto.c       | 111 ++++++++++++++++++++++++++++++++++++++++---
 block/crypto.h       |   9 ++++
 qapi/block-core.json |   6 ++-
 qapi/crypto.json     |   6 ++-
 4 files changed, 124 insertions(+), 8 deletions(-)

-- 
2.17.1



             reply	other threads:[~2024-11-28 11:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-28 10:51 tugy [this message]
2024-11-28 10:51 ` [PATCH 1/2] crpyto: support encryt and decrypt parallelly using thread pool tugy
2024-11-28 10:51 ` [PATCH 2/2] qapi/crypto: support enable encryption/decryption in parallel tugy
2025-01-17 13:04   ` Daniel P. Berrangé
2024-12-13  8:26 ` [PATCH 0/2] support block " Guoyi Tu
2024-12-13 15:56 ` Daniel P. Berrangé
2025-01-16 12:37   ` Kevin Wolf
2025-01-17 12:55     ` Daniel P. Berrangé
2025-01-18 14:39       ` Guoyi Tu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1732789721.git.tugy@chinatelecom.cn \
    --to=tugy@chinatelecom.cn \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.