DavidGF
Members
-
Joined
-
Last visited
Reputation Activity
-
DavidGF got a reaction from sfx2000 in Helios4 - Cryptographic Engines And Security Accelerator (CESA) BenchmarkingNot sure whether it's a good idea to bump this thread but just my 2cts on this:
CESA is quite good for use cases such as LUKS. Obviously you will need to use aes-cbc (use 128 bits for maximum perf).
In this mode the CPU usage is quite low (you can see two kernel workers doing 10% on each CPU and a ton of interrupts, but other than that works well) which is awesome to keep the load of the CPU which is already limited. In comparison on using pure CPU, in my current setup I get:
- Plain access to disk: 180MB/s
- LUKS2 + CESA: 140MB/s
- LUKS2 (no CESA): 52MB/s
I tuned LUKS using sector size= 4096 and keysize=128, as well as using aes-cbc-plain64.
For me this is quite good already even tho CESA only supports some "relatively old" ciphers.
Hope this helps other people!
-
DavidGF got a reaction from gprovost in Helios4 - Cryptographic Engines And Security Accelerator (CESA) BenchmarkingNot sure whether it's a good idea to bump this thread but just my 2cts on this:
CESA is quite good for use cases such as LUKS. Obviously you will need to use aes-cbc (use 128 bits for maximum perf).
In this mode the CPU usage is quite low (you can see two kernel workers doing 10% on each CPU and a ton of interrupts, but other than that works well) which is awesome to keep the load of the CPU which is already limited. In comparison on using pure CPU, in my current setup I get:
- Plain access to disk: 180MB/s
- LUKS2 + CESA: 140MB/s
- LUKS2 (no CESA): 52MB/s
I tuned LUKS using sector size= 4096 and keysize=128, as well as using aes-cbc-plain64.
For me this is quite good already even tho CESA only supports some "relatively old" ciphers.
Hope this helps other people!
