Comment 10 for bug 119295

Revision history for this message
Craig Ringer (ringerc) wrote : No luck with the patch

That patch applies to openssl as shipped in Hardy, but doesn't appear to have any effect. After patching openssl, rebuilding the packages and installing them, `openssl engine padlock' reports:

(padlock) VIA PadLock (no-RNG, ACE)

on my C3 thin clients. That should get me at least accelerated aes-128, but yet:

openssl speed aes-128-cbc -engine padlock

loads the padlock engine successfully but does NOT appear to be using its crypto facilities. Performance remains miserable, around 10MB/s of aes-128-cbc throughput. SSH gets ~5 MB/s throughput, which seems reasonable given the other overheads it faces.

If I build openssl-0.9.8h upstream and test with that I also see no performance change.

The processor DOES report ACE support. CPUinfo:

flags : fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse up rng rng_en ace ace_en

There's no change when the padlock-aes module is loaded (but it shouldn't be needed for openssl/openssh anyway, as padlock is done in userspace with CPU instruction extensions).

It's like OpenSSL is silently falling back to software crypto at some level. I haven't dug into it deeply yet, but I thought it important to mention that the proposed fix does NOT appear to work on my hardware.

This support is *REALLY* important for use of C3/C7 machines as LTSP thin clients, because currently the X server and network (via ssh) fight for CPU, severely limiting performance. Using the hardware crypto should massively reduce SSH's CPU demands and dramatically boost performance.

Full CPUInfo:

processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 9
model name : VIA Nehemiah
stepping : 8
cpu MHz : 666.577
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse up rng rng_en ace ace_en
bogomips : 1334.91
clflush size : 32