Maamoun TK maamoun.tk@googlemail.com writes:
On Mon, Jul 20, 2020 at 8:41 PM Niels Möller nisse@lysator.liu.se wrote:
Latency less than one cycle sounds wrong.
I had the same concern, I measured the clock time from the start of the instruction execution until the start of the next dependent instruction. I'm sure about the latency numbers but not sure how to subtend them with cycle numbers.
You may need to have a *long* chain of depending instructions to get an accurate measurement of latency.
I take it "P8" in the path is for power 8? Are the crypto extensions always available for power 8? If not, directory should be named differently.
Yes, it stands for POWER8, it's the minimal processor that supports the crypto extensions, sticking crypto extensions with POWER8 is fine.
But in the patch for fat builds, you do the runtime check as
+ hwcap2 = getauxval(AT_HWCAP2);
+ features->have_crypto_ext = + (hwcap2 & PPC_FEATURE2_VEC_CRYPTO) == PPC_FEATURE2_VEC_CRYPTO ? 1 : 0;
I think I would prefer to have a matching directory name in the source tree, e.g., powerpc64/crypto_ext.
Are the aes instructions and the ghash instructions (which I imagine also has non-cryptographic uses) part of the same extension?
BTW, about fat tests, I'm considering adding a make target "check-fat" which will run make check with some different settings of NETTLE_FAT_OVERRIDE (platform specific, and determined by configure).
I can help implementing this feature if you give me more details on how to go with it.
The main thing I'm unsure about is that I don't know what extensions the ci test machines can be expected to have. For cross tests, it shouldn't be an issue as long as qemu supports all extensions of interest. But for a native x86_64 fat build, do the test machines have, e.g., the "sha_ni" extension? If not, we'd need to find out, and prune what fat variants we test.
Regards, /Niels