On Fri, Aug 5, 2011 at 9:49 AM, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Aug 04, 2011 at 08:19:23PM +0200, Mathias Krause wrote: >> This patch series adds an assembler implementation for the SHA1 hash algorithm >> for the x86-64 architecture. Its raw hash performance can be more than 2 times >> faster than the generic C implementation. This gives a real world benefit for >> IPsec with an throughput increase of up to +35%. For concrete numbers have a >> look at the second patch. > > I'll apply this as soon as rc1 is out. Thanks! > > PS if you have time please look into the asynchronous version. I've converted the implementation to ahash. It was pretty easy in the end as I had a reference to look at -- the ghash implementation. But I'm pretty unhappy how many layers of indirection are in there now even for the irq_fpu_usable() case -- not to mention that the !irq_fpu_usable() is much more heavyweight but, at least, it can now always make use of the SSE3 variant. (See the attached patch, but please don't apply it. It's compile tested only! Also I'm not comfortable with the ahash version right now.) I haven't made any benchmarks yet because I've no access to the test machine right now. But I suspect it'll be much slower for small chunks and *maybe* faster for the IPsec case I'm interested in because it can now always use the SSE3 variant. What I'm thinking about is having both, a shash and an ahash variant so the user can actually chose which interface fits its needs best -- e.g., dm-crypt might want to use the shash interface and xfrm the ahash one. Do you think something like that is possible? And if so, how would dm-crypt automatically chose the shash and xfrm the ahash variant? Regards, Mathias
Attachment:
0001-crypto-sha1-convert-to-ahash-interface.patch
Description: Binary data
