On 6/27/2011 1:13 PM, David Magda wrote:
On Mon, June 27, 2011 15:24, Erik Trimble wrote:
[...]
I'm always kind of surprised that there hasn't been a movement to create
standardized crypto commands, like the various FP-specific commands that
are part of MMX/SSE/etc. That way, most of this could be done in
hardware seamlessly.
The (Ultra)SPARC T-series processors do, but to a certain extent it goes
against a CPU manufacturers best (financial) interest to provide this:
crypto is very CPU intensive using 'regular' instructions, so if you need
to do a lot of it, it would force you to purchase a manufacturer's
top-of-the-line CPUs, and to have as many sockets as you can to handle a
load (and presumably you need to do "useful" work besides just
en/decrypting traffic).
If you have special instructions that do the operations efficiently, it
means that you're not chewing up cycles as much, so a less powerful (and
cheaper) processor can be purchased.
I'm sure all the Web 2.0 companies would love to have these (and OpenSSL
link use the instructions), so they could simply enable HTTPS for
everything. (Of course it'd also be helpful for data-at-rest, on-disk
encryption as well.)
The last benchmarks I saw indicated that the SPARC T-series could do 45
Gb/s AES or some such, with gobs of RSA operations as well
The T-series crypto isn't what I'm thinking of. AFAIK, you still need
to use the Crypto framework in Solaris to access the on-chip
functionality. Which makes the T-series no different than CPUs without a
crypto module but a crypto add-in board instead.
What I'm thinking of is something on the lines of what AMD proposed
awhile ago, in combination with how we used to handle hardware that had
FP optional.
That is, you continue to make CPUs without any crypto functionality,
EXCEPT that they support certain extensions a la MMX. If no Crypto
accelerator was available, the CPU would trap any Crypto calls, and
force them to done in software. You could then stick a crypto
accellerator in a second CPU socket, and the CPU would recognized this
was there, and pipe crypto calls to the dedicated co-processor.
Think about how things were done with the i386 and i387. That's what
I'm after. With modern CPU buses like AMD & Intel support, plopping a
"co-processor" into another CPU socket would really, really help.
--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
