On Sun, Jan 11, 2015 at 11:48:08PM -0500, Timothy McCaffrey wrote: > > This patch has been tested with Sandy Bridge and Haswell processors. With 128 > bit keys and input buffers > 512 bytes a slight performance degradation was > noticed (~1%). For input buffers of less than 512 bytes there was no > performance impact. Compared to 128 bit keys, 256 bit key size performance > is approx. .5 cycles per byte slower on Sandy Bridge, and .37 cycles per > byte slower on Haswell (vs. SSE code). Thanks Tim! While I think your patch should definitely be applied to the current GCM implementation, longer term I'd like to see some justification why we're adding these optimisations in the form of gcm-aesni rather than ghash-avx and ctr-aesni. Is there any reason why these optimisations can't be added to the standalone ghash or ctr(aes)? Or for that matter is there some fundamental synergy that I'm not seeing that you would only get by putting these into gcm-aesni? If the answers are no and no, then I'd like to see all these optimisations migrated over to ghash and ctr(aes) and then we can simply remove gcm-aesni. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
