On Thu, Apr 30, 2009 at 11:29:13AM -0700, Matthew Dempsky wrote: > I've been thinking of playing with improving the speed of OpenBSD's > cryptography primitives. My tentative plans: > > - benchmark aes-ctr performance with current code vs. optimized > assembly code (e.g., just hacking sys/crypto/rijndael.c to use > optimized code); if no significant improvement, abort
Careful with benchmarks: they often don't tell you what you want to know, usually the opposite. If you benchmark, try to find the cause for the reason your benchmark shows you whatever it does. If this all sounds obvious to you, I apologise, but this point seems to be missed alot. > - add new drivers that attach on specific CPUs and hook into the > crypto framework to provide optimized implementations Even if it isn't faster, it may allow the cpu to do something else in the meantime. That is a good thing. > - add support for i386/amd64 to allow limited FPU/MMX/SSE use in the kernel Not my area, but when programming kernel, there's some rules, I think 'thou shalt not use floating point' being one of them. Ask when in doubt (i.e. when you want to use something cool instruction-set wise). > - repeat above, including implementations that take advantage of > FPU/MMX/SSE instructions I'm slightly worried that we might have: - one implementation for i386/amd64 - one implementation for the rest This makes keeping track of mistakes and merging diffs in the two harder. > - experiment with adding new stream ciphers (e.g., Salsa20) > - experiment with making swcr_encdec better aware of stream ciphers > to avoid unnecessary copying to fit block-size or padding > - experiment with adding new MACs (e.g., Poly1305) Crypto is totally not my area. No comments here. > My long term goal/hope is to speed up IPsec, but in the interim I only > have one machine to work with, so for now I'll probably just measure > the time it takes to handle requests from user-space. It appears your initial thesis is that crypto is slow because of how the (machine) code of the algorithm looks. Please confirm this first. As Ted Unangst mentioned, context switches might be a cause for speed degradation. > If anyone has feedback/suggestions on the above plans, I'm happy to hear them. -- Ariane
