On Wed, Dec 14, 2016 at 12:55 PM, Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > Hey Tom, > > Just following up on what I mentioned in my last email... > > On Wed, Dec 14, 2016 at 8:35 PM, Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: >> I think your suggestion for (2) will contribute to further >> optimizations for (1). In v2, I had another patch in there adding >> siphash_1word, siphash_2words, etc, like jhash, but I implemented it >> by taking u32 variables and then just concatenating these into a >> buffer and passing them to the main siphash function. I removed it >> from v3 because I thought that these kind of missed the whole point. >> In particular: >> >> a) siphash24_1word, siphash24_2words, siphash24_3words, etc should >> take u64, not u32, since that's what siphash operates on natively > > I implemented these here: > https://git.zx2c4.com/linux-dev/commit/?h=siphash&id=4652b6f3643bdba217e2194d89661348bbac48a0 > Those look good, although I would probably just do 1,2,3 words and then have a function that takes n words like jhash. Might want to call these dword to distinguish from 32 bit words in jhash. Also, what is the significance of "24" in the function and constant names? Can we just drop that and call this siphash? Tom > This will be part of the next version of the series I submit. It's not > immediately clear that using it is strictly faster than the struct > trick though. However, I'm not yet sure why this would be. > > Jason -- 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
