|
Date: Mon, 12 Dec 2016 22:44:09 +0100 From: "Jason A. Donenfeld" <Jason@...c4.com> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, LKML <linux-kernel@...r.kernel.org>, Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, George Spelvin <linux@...izon.com>, Scott Bauer <sbauer@....utah.edu>, Andi Kleen <ak@...ux.intel.com>, Andy Lutomirski <luto@...capital.net>, Greg KH <gregkh@...uxfoundation.org>, Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>, "Daniel J . Bernstein" <djb@...yp.to> Subject: Re: [PATCH v2] siphash: add cryptographically secure hashtable function Hi Linus, > I guess you could try to just remove the "if (left)" test entirely, if > it is at least partly the mispredict. It should do the right thing > even with a zero count, and it might schedule the code better. Code > size _should_ be better with the byte mask model (which won't matter > in the hot loop example, since it will all be cached, possibly even in > the uop cache for really tight benchmark loops). Originally I had just forgotten the `if (left)`, and had the same sub-par benchmarks. In the v3 revision that I'm working on at the moment, I'm using your dcache trick for cases 3,5,6,7 and short-circuiting cases 1,2,4 to just directly access those bytes as integers. For the 32-bit case, I do something similar, but built inside of the duff's device. This should give optimal performance for the most popular use cases, which involve hashing "some stuff" plus a leftover u16 (port number?) or u32 (ipv4 addr?). #if defined(CONFIG_DCACHE_WORD_ACCESS) && BITS_PER_LONG == 64 switch (left) { case 0: break; case 1: b |= data[0]; break; case 2: b |= get_unaligned_le16(data); break; case 4: b |= get_unaligned_le32(data); break; default: b |= le64_to_cpu(load_unaligned_zeropad(data) & bytemask_from_count(left)); break; } #else switch (left) { case 7: b |= ((u64)data[6]) << 48; case 6: b |= ((u64)data[5]) << 40; case 5: b |= ((u64)data[4]) << 32; case 4: b |= get_unaligned_le32(data); break; case 3: b |= ((u64)data[2]) << 16; case 2: b |= get_unaligned_le16(data); break; case 1: b |= data[0]; } #endif It seems like this might be best of all worlds? Jason
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.