[Bug 242747] AMD Epyc+GELI not using Hardware AES

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Fri Dec 20 22:28:45 UTC 2019


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242747

            Bug ID: 242747
           Summary: AMD Epyc+GELI not using Hardware AES
           Product: Base System
           Version: 12.1-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: nevans at talkpoint.com

Created attachment 210085
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=210085&action=edit
Xeon/Epyc Server Information

I have two similar systems I'm testing as database hardware. Both consist of 8x
Samsung 860 Pro SSD's attached to LSI9003-8i, 256GB ram, equal
chassis/backplane. The only variance is one server is an Epyc 7371, and the
other a Xeon Gold 6130. I've attached some command snippets to show
configuration info

There are 8 configured SSD's in each all the same setup as the ones I listed in
a ZFS raid 10 setup with 4 mirrored vdevs. I'm aware that GELI is setup with 4k
aligned sectors vs the drives reported 512 bytes, it should be a non-factor for
the behavior I'm seeing. Long and short is, despite the Epyc box reporting that
it supports AES like the Xeon as well as GELI showing Crypto: hardware, when I
extract a tar of my 100GB test database to each server the load of the Epyc box
is significantly higher with top showing tons of CPU time on g_eli threads that
the Xeon does not have when in hardware mode. When I disable the aesni and
cryptodev modules on the Xeon I get the same behavior with high g_eli thread
load which leads me to believe that depsite Epyc/GELI reporting they're using
hardware AES it's actually still running in software mode. I've tried with both
AES-XTS and AES-CBC modes for GELI with the same behavior. Both servers are
fully research at the moment so I can try any necessary tests/fixes to drill
down on this.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list