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

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.

> 
> 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.

Regards,
Hendrik

> 
> - Eric