What happened to the MAUs on T4?

Crypto background

One of the powerful features of the SPARC T-series servers is its hardware crypto acceleration, which dramatically speeds up the compute intensive algorithms needed to encrypt and decrypt data.

The SPARC T1, T2, T2+ and SPARC-T3 all have MAUs ("modular arithmetic units", named after the original function provided with the T1). Subsequent models added cryptographic algorithms to accelerate RSA, DSA, Diffie-Hellman, RC4, DES, 3DES, AES, MD5, SHA-1, SHA-n, and ECC, but they were still packaged as a separate resource on each T-series core. That changed with the SPARC T4, which is discussed below.

Administrators setting up logical domains on the older T-series servers had to explicitly assign crypto resources to domains that had a significant crypto workload (say, an SSL based web server). This could be an administrative burden, as you had to choose which domains got the crypto units, and issue the appropriate ldm set-mau N mydomain commands. Further, not all domains that could benefit from hardware-based crypto acceleration could benefit it. (In practice, this could only happen if you allocated very small domains that use only part of a CPU core, since each core had its own MAU. One wouldn't do that for a domain with serious performance requirements anyway.)

The T4 changes things

The T4 is fast. Really fast. Its clock rate and out-of-order (OOO) execution that provides the single-thread performance that T-series machines previously did not have. If you have any preconceptions about T-series performance, or SPARC in general, based on the older servers (which, it must be said, were absolutely outstanding for multi-threaded applications), those assumptions are now obsolete. The T4 provides outstanding. performance for all kinds of workload, as illustrated at https://blogs.oracle.com/bestperf.

While we all focused on this (did I mention the T4 is fast?), another feature of the T4 went largely unnoticed: The T4 servers have improved crypto acceleration, described at https://blogs.oracle.com/DanX/entry/sparc_t4_openssl_engine. It is "just built in" so administrators no longer have to assign crypto accelerator units to domains - it "just happens". Every physical or virtual CPU on a SPARC-T4 has full access to hardware based crypto acceleration at all times.

This is much better since you have crypto everywhere by default without having to manage it as a discrete and limited resource. It's a feature of the processor, like doing an integer add. With T4, there is no management necessary, you just have HW crypto everywhere all the time seamlessly.

This change hasn't been widely advertised, and some administrators have wondered why there were unable to assign a MAU to a domain as they did with T2 and T3 machines. The answer is that there is no longer any separate MAU, so you don't have to take any action at all - just leave the default of 0. For completeness sake, it's worth noting that the T4 adds more crypto algorithms, and accelerates Camelia, CRC32c, and more SHA-x.

Summary

Besides being much faster than its predecessors, the T4 also integrates hardware crypto acceleration so its seamlessly available to applications, whether domains are being used or not. Administrators no longer have to control how they are allocated - it is available to all CPUs and virtual environments without any administrative effort.

Comments:

If you have an application that requires encryption (i.e. HTTPS, SNMPv3, SSL, SSH, firefox, wget[https], etc.) - how can can one tell if the crypto processors are being leveragaed on the T4, T3, T2+, T2, or T1?

I am trying to understand, how a systems administrator could check, so packages can be updated or so application support people can go back to their vendors and make enhancement requests.

Posted by DavidH on June 06, 2012 at 02:30 PM MST #

Hi David,

If it's Solaris 11, you can issue the command "openssl engine". On Solaris 10 and 11, you can issue 'cryptoadm list'. Output will depend on the processor type and Solaris level. However, a Java application using the default JCE provider will automatically get it right, as will any application going through libpkcs11. It should be transparent to applications since they can leverage those frameworks for getting to the crypto engines. A vendor that wants to check for itself can test for being on T4 (prtconf will tell you). I hope that's helpful. regards, Jeff

Posted by Jeff on June 06, 2012 at 05:41 PM MST #

Post a Comment:
Comments are closed for this entry.
About

jsavit

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today