Re: [PATCH] crypto: qat - lower priority for skcipher and aead algorithms

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 16, 2025 at 12:18:02PM +0800, Herbert Xu wrote:
> On Fri, Jun 13, 2025 at 11:32:27AM +0100, Giovanni Cabiddu wrote:
> > Most kernel applications utilizing the crypto API operate synchronously
> > and on small buffer sizes, therefore do not benefit from QAT acceleration.
> 
> So what performance numbers should we be getting with QAT if the
> buffer sizes were large enough?

Specifically for AES128-XTS, under optimal conditions, the current
generation of QAT (GEN4) can achieve approximately 12 GB/s throughput at
4KB block sizes using a single device. Systems typically include between
1 and 4 QAT devices per socket and each device contains two internal
engines capable of performing that algorithm.

This level of performance is observed in userspace, where it is possible
to (1) batch requests to amortize MMIO overhead (e.g., multiple requests
per write), (2) submit requests asynchronously, (3) use flat buffers
instead of scatter-gather lists, and (4) rely on polling rather than
interrupts.

However, in the kernel, we are currently unable to keep the accelerator
sufficiently busy. For example, using a synthetic synchronous and single
threaded benchmark on a Sapphire Rapids system, with interrupts properly
affinitized, I observed throughput of around 500 Mbps with 4KB buffers.
Debugfs statistics (telemetry) indicated that the accelerator was
utilized at only ~4%.

Given this, VAES is currently the more suitable choice for kernel use
cases. The patch to lower the priority of QAT's symmetric crypto
algorithms reflects this practical reality. The original high priority
(4001) was set when the driver was first upstreamed in 2014 and had not
been revisited until now.

That said, symmetric encryption support in QAT remains relevant for
chained operations, where compression and encryption can be offloaded in
a single request. This capability is planned for full support in GEN6
and may be backported to GEN4 if there is sufficient demand. However,
there is currently no infrastructure or in-kernel user for this
functionality.

Regards,

-- 
Giovanni




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux