From: Eric Biggers
> Sent: 07 January 2017 22:09
..
> Out of curiosity, is this actually a solvable problem, e.g. by making the code
> using the XMM registers responsible for saving and restoring the ones
> clobbered,
> or by optimizing kernel_fpu_begin()/kernel_fpu_end()? Or does it in fact
> r
Hi David,
On Sat, Jan 7, 2017 at 10:37 PM, David Miller wrote:
> This and the next patch are a real shame, performance wise, on cpus
> that have single-instruction SHA1 and MD5 implementations. Sparc64
> has both, and I believe x86_64 can do SHA1 these days.
>
> It took so long to get those inst
From: Eric Biggers
Date: Sat, 7 Jan 2017 14:09:11 -0800
> Well, except those instructions aren't actually used in these
> places. Although x86_64 SHA1-NI accelerated SHA-1 is available in
> the Linux crypto API, it seems that in kernel code it remains
> impractical to use these instructions on s
Hi David,
On Sat, Jan 07, 2017 at 04:37:36PM -0500, David Miller wrote:
> From: "Jason A. Donenfeld"
> Date: Sat, 7 Jan 2017 15:40:56 +0100
>
> > This gives a clear speed and security improvement. Siphash is both
> > faster and is more solid crypto than the aging MD5.
[snip]
>
> This and the n
From: "Jason A. Donenfeld"
Date: Sat, 7 Jan 2017 15:40:56 +0100
> This gives a clear speed and security improvement. Siphash is both
> faster and is more solid crypto than the aging MD5.
>
> Rather than manually filling MD5 buffers, for IPv6, we simply create
> a layout by a simple anonymous st
This gives a clear speed and security improvement. Siphash is both
faster and is more solid crypto than the aging MD5.
Rather than manually filling MD5 buffers, for IPv6, we simply create
a layout by a simple anonymous struct, for which gcc generates
rather efficient code. For IPv4, we pass the va
