On Mon, Nov 2, 2009 at 11:58 AM, Dennis Clarke <dcla...@blastwave.org> wrote:
>
>>> Terrific! Can't wait to read the man pages / blogs about how to use
>>> it...
>>
>> Just posted one:
>>
>> http://blogs.sun.com/bonwick/en_US/entry/zfs_dedup
>>
>> Enjoy, and let me know if you have any questions or suggestions for
>> follow-on posts.
>
> Looking at FIPS-180-3 in sections 4.1.2 and 4.1.3 I was thinking that the
> major leap from SHA256 to SHA512 was a 32-bit to 64-bit step.
>
> If the implementation of the SHA256 ( or possibly SHA512 at some point )
> algorithm is well threaded then one would be able to leverage those
> massively multi-core Niagara T2 servers. The SHA256 hash is based on six
> 32-bit functions whereas SHA512 is based on six 64-bit functions. The CMT
> Niagara T2 can easily process those 64-bit hash functions and the
> multi-core CMT trend is well established. So long as context switch times
> are very low one would think that IO with a SHA512 based de-dupe
> implementation would be possible and even realistic. That would solve the
> hash collision concern I would think.
>
> Merely thinking out loud here ...
And my out loud thinking on this says that the crypto accelerator on a
T2 system does hardware acceleration of SHA256.
NAME
n2cp - Ultra-SPARC T2 crypto provider device driver
DESCRIPTION
The n2cp device driver is a multi-threaded, loadable
hardware driver supporting hardware assisted acceleration of
the following cryptographic operations, which are built into
the Ultra-SPARC T2 CMT processor:
DES: CKM_DES_CBC, CKM_DES_ECB
DES3: CKM_DES3_CBC, CKM_DES3_ECB,
AES: CKM_AES_CBC, CKM_AES_ECB, CKM_AES_CTR
RC4: CKM_RC4
MD5: KM_MD5, CKM_MD5_HMAC, CKM_MD5_HMAC_GENERAL,
CKM_SSL3_MD5_MAC
SHA-1: CKM_SHA_1, CKM_SHA_1_HMAC,
CKM_SHA_1_HMAC_GENERAL, CKM_SSL3_SHA1_MAC
SHA-256:CKM_SHA256, CKM_SHA256_HMAC,
CKM_SHA256_HMAC_GENERAL
According to page 35 of
http://www.slideshare.net/ramesh_r_nagappan/wirespeed-cryptographic-acceleration-for-soa-and-java-ee-security,
a T2 CPU can do 41 Gb/s of SHA256. The implication here is that this
keeps the MAU's busy but the rest of the core is still idle for things
like compression, TCP, etc.
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
