Re: [PATCH 1/2] crypto: pcrypt - Remove pcrypt

Hallo,

On 7/22/26 21:40, Eric Biggers wrote:
> On Wed, Jul 22, 2026 at 06:12:16PM +0200, Hendrik Donner wrote:
>> Hello,
>>
>> On 7/21/26 21:50, Eric Biggers wrote:
>>> On Tue, Jul 21, 2026 at 08:59:21PM +0200, Hendrik Donner wrote:
>>>> Hello,
>>>>
>>>> On 7/14/26 00:32, Eric Biggers wrote:
>>>>> pcrypt was originally intended to improve IPsec performance.  However,
>>>>> it's no longer useful for that.  Reports from the rare cases that anyone
>>>>> has actually tried to use it over the years indicate that it actually
>>>>> reduces IPsec performance, e.g.:
>>>>>
>>>>> * https://github.com/libreswan/libreswan/wiki/Internals:-Cryptographic-Acceleration#obsoleted-ipsec-accelerations
>>>>> * https://users.strongswan.narkive.com/liqTaTq8/strongswan-problem-with-pcrypt
>>>>> * https://unix.stackexchange.com/questions/594336/ipsec-multithreading-via-pcrypt-worse-than-single-thread
>>>>>
>>>>> It's also undocumented and quite difficult to actually use.  Its design
>>>>> is also broken, in that any unprivileged program can enable pcrypt
>>>>> systemwide at any time (by instantiating it using AF_ALG).
>>>>>
>>>>> Meanwhile, pcrypt has been a regular source of bugs, including at least
>>>>> four that have received CVEs.
>>>>>
>>>>> Let's just remove it.  No one seems to care about it anymore other than
>>>>> people looking for vulnerabilities.
>>>>>
>>>>
>>>> my company is a user. We have a hardware platform based on an IMX6 SoC
>>>> using IPSec and configure pcrypt using crconf. Current performance
>>>> difference:
>>>>
>>>> iperf3 -c <IP> --time 60 -R
>>>>
>>>> pcrypt:
>>>> Download: 107 Mbits/sec
>>>>
>>>> No pcrypt:
>>>> Download: 59.3 Mbits/sec
>>>>
>>>> iperf3 -c <IP> --time 60
>>>>
>>>> pcrypt:
>>>> Upload: 65.9 Mbits/sec
>>>>
>>>> No pcrypt:
>>>> Upload: 52.0 Mbits/sec
>>>>
>>>> The relevant crypto templates are configured in early userspace and
>>>> since i got curious, that has been the case since 2017.
>>>>
>>>> Mostly using
>>>>
>>>> pcrypt(gcm_base(ctr-aes-neonbs,ghash-generic))
>>>>
>>>> nowadays, AES-CBC in the past/as a fallback option.
>>>>
>>>> So at least on some platforms there is still a significant performance
>>>> boots, at least for downloads in this case.
>>>
>>> Thanks for bringing up your use case.
>>>
>>> Have you looked into alternative solutions such as Receive Side Scaling
>>> (https://docs.kernel.org/networking/scaling.html#rss-receive-side-scaling)?
>>> AFAIK it's not just the crypto performance that makes pcrypt unnecessary
>>> these days, but also the design of the networking layer.
>>
>> I'm looking into this more, the IMX.6 is a bit limited with IRQ handling and
>> queue distribution.
> 
> Thanks!  Maybe Steffen and the other IPsec folks would have some advice
> too.
> 

so i'm now on 7.1.4 with

   PCI: imx6: Keep i.MX6 Root Port MSI/MSI-X Capabilities with iMSI-RX 
to work around hardware bug

on top to be able to tune queue settings. And to have a working ethernet
in the first place, without the patch the NETDEV WATCHDOG resets the
card all the time due to queues stalling. But now more than 1 CPU are
serving IRQs.

With pcrypt
(seqiv(rfc4106(pcrypt(gcm_base(ctr-aes-neonbs,ghash-lib))))):

Upload:
[  4]   0.00-60.00  sec   901 MBytes   126 Mbits/sec

Download:
[  4]   0.00-60.00  sec  1.23 GBytes   177 Mbits/sec

Without pcrypt
(seqiv(rfc4106(gcm_base(ctr-aes-neonbs,ghash-lib)))):

Upload:
[  4]   0.00-60.00  sec   679 MBytes  94.9 Mbits/sec

Download:
[  4]   0.00-60.00  sec   674 MBytes  94.3 Mbits/sec

So counterintuitively pcrypt matters more again. I repeated the tests a
few times, those numbers are fairly representative. Every run is over a
60 sec window.

Regards,
Hendrik

>>> I understand that i.MX6 doesn't have the ARMv8 crypto extensions.
>>> However, surely you could at least use the NEON-optimized GHASH code?
>>> Is there a reason you're not using it?
>>
>> I think it was historically not working well for us, retested:
>>
>> NEON GHASH with pcrypt:
>>
>> Download: 116 Mbits/sec
>> Upload: 74.3 Mbits/sec
>>
>> NEON GHASH baseline:
>>
>> Download: 90.7 Mbits/sec
>> Upload: 60.8 Mbits/sec
>>
>> Looks better, still a ~15 Mbit improvement with pcrypt.
>>
>> I want to point out that without IPSec our baseline is:
>>
>> Download: 942 Mbits/sec
>> Upload: 942 Mbits/sec
>>
>> Intel IGB ethernet.
> 
> That already shows that about two-thirds of the improvement you were
> getting from pcrypt can be gotten just by using the correct GHASH
> implementation for the platform (59.3 => 90.7 download, vs 59.3 => 107;
> and 52.0 => 60.8 upload, vs 52.0 => 65.9).
> 
> And with that new baseline, for downloads, pcrypt adds just 28% more
> throughput (90.7 => 116) rather than 80% as it did before (59.3 => 107).
> 
> It seems clear that the usefulness of pcrypt rapidly decreases as the
> actual crypto gets faster.
> 
> Note: we've been enabling crypto optimizations by default in recent
> kernels, so that people can no longer use the generic code by accident.
> For example in v7.1 and later, GHASH optimizations are always enabled.
> 
> I'm working on further optimizations to the AES-GCM code as well,
> specifically implementing AES-GCM directly on all platforms without the
> inefficient gcm_base template that is being used here.
> 
> So while maybe pcrypt does still help a bit on this platform for now,
> the approach does seem quite dated and largely a workaround for
> inefficiencies elsewhere in the stack (including systems where the
> optimized crypto code is accidentally not enabled).
> 
> - Eric