Re: [PATCH v5 0/2] Add support for Texas Instruments DTHE V2 crypto accelerator

[Simon Richter]

Hi,

On 6/17/25 13:27, Eric Biggers wrote:

> Numbers, please.  What is the specific, real use case in Linux where this
> patchset actually improves performance?  Going off the CPU and back again just
> to en/decrypt some data is hugely expensive.

It would be cool to get some numbers from the IBM folks as well -- the 
NX coprocessor can do AES and SHA, but it is not enabled in the Linux 
kernel, only GZIP is (where I can definitely see a benefit, usually 
somewhere between 3 to 9 GB/s depending on how hard it needs to look for 
repetitions), so I'm wondering if that is an oversight, or deliberate.

I also wonder if for some hardware, we can get a speedup by offloading 
and polling for completion instead of waiting for an interrupt. It feels 
wrong, but the thread is blocked no matter what.

The other thing to ponder would be whether we can define a data size 
threshold where the offloading overhead becomes small enough that it's 
still worth it. That would also work for fscrypt, because with 4k 
blocks, it would simply never choose the offload engine.

   Simon