AESNI acceleration is not enabled on any AMD processors (and hence on Ryzens). As a result, when configuring samba with encryption the performance is very poor. Looking at the code, I can see that the problems like in lib/crypto/aes.c where the code checks for cpuid reg0 (has_intel_aes_instructions) (pseudo code): if (cpu_results != "IntelGenuine") return false Obviously on AMD processors, the value is AuthenticAMD, and therefore the code fails to detect the acceleration. I changed the code to recognize the processor, and I was then able to use AESNI (or at least performance went up, CPU usage down, and perf record shows the aesni assembly being invoked ;-)) on either my Ivy Bridge (where it was working before the patch), and Ryzen machines. I am not sure why the code is specifically checking for Intel instead of accepting AMD and Intel (or for that matter any other clone), so I might be missing something, but either removing the if on genuineintel, or or'ing with authenticamd should work just fine (I did not see such checks in the linux kernel, but I might have missed it). One concern with my patch is that I do have access to an Ivy Bridge and Ryzen, but I do not have access to a battery of various processors to see if they exhibit a weird behavior that the previous code was handling. related to bug 13008 which added support for Intel processors (but not amd's).
*scratches head* ENOPATCH?
Sorry, my employer has not agreed yet to my contributing the patch. Though, the patch is trivial, so should somebody have the time to write the couple of lines that I suggested, it might get done before my employer approves my contribution. Thanks for understanding.
Created attachment 14067 [details] Fixes bug (adds AESNI support for AMD processors)
Comment on attachment 14067 [details] Fixes bug (adds AESNI support for AMD processors) you already mentioned that the check for the vendor should be removed or extended. As the cpuid flag 25 is always the aes instruction set on x86, the check should just be removed actually here.
Björn, as the __cpuid(cpuid_results, 1) seem to be standard, as https://en.wikipedia.org/wiki/CPUID show cpuid(1) with is supported on a pentium or above. Looks like we could just remove the check for vendor and always just directly check for bit 25 and if so assume AES instructions - correct ?
Created attachment 14076 [details] git-am fix for master. Bjorn and Eric, does this patch work for you ?
Created attachment 14077 [details] Revised git-am fix for master. Slightly better fix that doesn't zero out cpuid_results[] each time we check the has_aes_instructions bool, but only once on initial check.
Created attachment 14078 [details] Proposed patch for all processors Jeremy, lgtm. Though, I am not sure the zero'ing is necessary: cpuid asm will store into the four locations (maybe I am missing something). Maybe, as well, rename has_intel ... to has_aes since this is no longer about intel (and the instructions are called AESNI) ? See proposed patch.
Comment on attachment 14078 [details] Proposed patch for all processors OK, LGTM I'm ok with this. Björn or Ralph can you +1 and I'll push to master & cherry-pick for back-ports.
Comment on attachment 14078 [details] Proposed patch for all processors lgtm, thanks!
Comment on attachment 14078 [details] Proposed patch for all processors Hang on a minute. I didn't stop this initially as it doesn't break on gcc, but this patch renames the has_intel_aes_instructions() function to has_aes_instructions(), which can conflict with the static static int has_aes_instructions = -1; I don't think this breaks on gcc, but might on clang or other proprietary compilers, plus it's very bad form. I'll commit a version of this that doesn't rename has_intel_aes_instructions(). Jeremy.
Created attachment 14087 [details] git-am fix for 4.7.next, 4.8.next. Cherry-picked from master. Applies cleanly to 4.7.next, 4.8.next.
(In reply to Jeremy Allison from comment #12) Pushed to autobuild-v4-[8,7]-test.
(In reply to Karolin Seeger from comment #13) Pushed to both branches. Closing out bug report. Thanks!