Re: [PATCH 0/3] Add support for qcrypto on shikra

[Kuldeep Singh]

> It sounds like you don't actually have an answer to my questions, then.
> 
> Performance tests (e.g.
> https://lore.kernel.org/r/20250615031807.GA81869@sol/) have clearly
> shown that this driver is an order of magnitude slower than the CPU.
> 
> This driver has historically been quite harmful.  People were using it
> accidentally and encountering very bad performance, as well as bugs such
> as crashes and filesystem hangs.  We fixed that by lowering its
> cra_priority.  But for the same reason, even when enabled on a platform,
> it's not actually used.  Linux would be better without this driver.
>

+Bartosz, Gaurav, Neeraj

Hi Eric,

GPCE is relevant in terms of providing hardware security.
There are multiple usecases coming up for example to handle DRM/secure
buffer usecases to improve overall throughput for secure content.

Regarding performance, it's currently slower compared to arm CE but
provides an edge by giving hardware security which is considered more
secure.

Btw, there's been performance improvement with new targets and we are
expecting to achieve far more better performance with new SoCs family.
Pakala:    GPCE - 550MBps, ARMv8 - 8GBps
Kaanapali: GPCE - 3GBps,   ARMv8 - 10GBps

Please note, there's almost 5x improvement in kaanapali compared to
pakala. Though overall is still slower compared to arm but as mentioned,
expecting better performance with hardware improvements as we progress.

Also, currently qce driver exhibit stability issues and that's what we
are putting effort in stabilizing the software on immediate basis.

There's parallel effort ongoing by Bartosz to introduce baseline for
secure buffer usecases.
https://lore.kernel.org/lkml/20260522-qcom-qce-cmd-descr-v18-0-99103926bafc@xxxxxxxxxxxxxxxx/
There's active development ongoing and i believe lowering cra_priority
for qce is fine as of now and can scale values once qce becomes
performance efficient.

Please share your thoughts. Thanks!

-- 
Regards
Kuldeep