Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Dec 2016 17:37:12 +0100
From: "Jason A. Donenfeld" <>
To: George Spelvin <>
Cc: Andi Kleen <>, David Miller <>, 
	David Laight <>, "Daniel J . Bernstein" <>, 
	Eric Biggers <>, Eric Dumazet <>, 
	Hannes Frederic Sowa <>, 
	Jean-Philippe Aumasson <>,, 
	Linux Crypto Mailing List <>, LKML <>, 
	Andy Lutomirski <>, Netdev <>, 
	Tom Herbert <>, Linus Torvalds <>, 
	"Theodore Ts'o" <>, Vegard Nossum <>
Subject: Re: HalfSipHash Acceptable Usage

Hi George,

On Wed, Dec 21, 2016 at 4:55 PM, George Spelvin
<> wrote:
> Actually, DJB just made a very relevant suggestion.
> As I've mentioned, the 32-bit performance problems are an x86-specific
> problem.  ARM does very well, and other processors aren't bad at all.
> SipHash fits very nicely (and runs very fast) in the MMX registers.
> They're 64 bits, and there are 8 of them, so the integer registers can
> be reserved for pointers and loop counters and all that.  And there's
> reference code available.
> How much does kernel_fpu_begin()/kernel_fpu_end() cost?

In my experience, these functions are only worth calling when
processing more significant amounts of data. I don't have any
benchmarks, but when I _remove_ all of these calls in a kernel,
accelerated crypto gets noticeably faster (until the system crashes).
We can measure it, though.

By the way, if somehow SipHash becomes acceptably fast on x86, would
you consider HalfSipHash for hash tables to be no longer needed? Or do
you suspect that HalfSipHash will always be faster even on, say,
32-bit ARM.


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.