On 06/01/2022 06:07, Eric Biggers wrote:
On Wed, Jan 05, 2022 at 09:55:17PM +0000, Bae, Chang Seok wrote:
+-----------+---------------+---------------+
| Cipher | Encryption | Decryption |
| (AES-KL) | (MiB/s) | (MiB/s) |
+-----------+---------------+---------------+
| AES-CBC | 505.3 | 2097.8 |
| AES-XTS | 1130 | 696.4 |
+-----------+-------------------------------+
Why is AES-XTS decryption so much slower than AES-XTS encryption? They should
be about the same.
Analyzing and understanding this with specific hardware implementation takes
time for us. Will come back and update you when we have anything to share here.
Note that for disk encryption, decryption performance is usually more important
than encryption performance. So your performance results are strange.
If the test results are from "cryptsetup benchmark", it just run benchmark
through userspace crypto API (AF_ALG) - no dm-crypt is involved at all.
Proper test with dm-crypt should be run to get some numbers too.
(But the test results are really strange... there is no reason
decryption should be slower for XTS.)
Also you mention that
Bare metal disk encryption is the only use case intended by these patches.
Userspace usage is not supported because there is no ABI provided to
communicate and coordinate wrapping-key restore failures to userspace.
The cryptsetup benchmark is userspace use (just with kernel netlink
access to kernel crypto). So I am not sure if these number are so important.
Milan
