On Mon, 2015-01-12 at 17:06 +1100, Herbert Xu wrote: > 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? Herbert, To quote Vinod who wrote the original gcm-aesni code, the reason to combine the ghash and ctr(aes) is as follow: "AES-GCM gets a lot of performance due to a fine-grained stitching of AES with GHASH. Depending on the uarch, a majority of the GHASH computation can be hidden within the AES." Adding Vinod also to this mail thread. Tim > > 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, -- 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
