On Fri, May 8, 2009 at 12:37 AM, Matthew Dempsky wrote:
> The eBACS project[1]
> times a bunch of different algorithms and implementations on a bunch
> of different CPUs.
[1] http://bench.cr.yp.to
On Thu, Apr 30, 2009 at 11:29 AM, Matthew Dempsky wrote:
> - 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
I didn't have the time to devote to this that I was
On 2009-05-01, Matthew Dempsky wrote:
> On Thu, Apr 30, 2009 at 6:05 PM, Stuart Henderson
> wrote:
>> I think you may need to update binutils before you can try these
>> fastest implementations..
>
> Why do you think that? I just successfully compiled Peter Schwabe's
> record setting AES implem
> For instance, you have a hifn and a via cpu. Which does [should] crypto use?
It should use the via, since it is way way way faster :)
On Thu, Apr 30, 2009 at 10:18 PM, Theo de Raadt
wrote:
> Again, you have not said what you want to do.
Er, sorry, I thought that email applied regardless.
> Do you want the kernel to do crypto faster, or do you want userland to
> do crypto fast.
The kernel to do crypto faster, hence the email s
> On Thu, Apr 30, 2009 at 9:42 PM, Ted Unangst wrote:
> > If you turn on cryptodevallowsoft and run openssl speed -evp
> > aes-128-cbc, you can watch the crypto thread in the kernel soaking up
> > cpu. In order for the thread to be running, you're definitely context
> > switching to it.
>
> Oops
On Thu, Apr 30, 2009 at 9:42 PM, Ted Unangst wrote:
> If you turn on cryptodevallowsoft and run openssl speed -evp
> aes-128-cbc, you can watch the crypto thread in the kernel soaking up
> cpu. In order for the thread to be running, you're definitely context
> switching to it.
Oops, yeah, Marco
On Thu, Apr 30, 2009 at 11:49 PM, Matthew Dempsky wrote:
> On Thu, Apr 30, 2009 at 6:53 PM, Marco Peereboom wrote:
>> listen to ted; he told you the real reason why it is slow.
>
> Ted said it's slow because of the context switches, but Theo confirmed
> that there are no context switches for the
On Thu, Apr 30, 2009 at 6:05 PM, Stuart Henderson wrote:
> I think you may need to update binutils before you can try these
> fastest implementations..
Why do you think that? I just successfully compiled Peter Schwabe's
record setting AES implementations for the Core 2, Athlon 64, and
Pentium 4
On Thu, Apr 30, 2009 at 6:53 PM, Marco Peereboom wrote:
> listen to ted; he told you the real reason why it is slow.
Ted said it's slow because of the context switches, but Theo confirmed
that there are no context switches for the soft crypto code, which is
what I'm interested in.
listen to ted; he told you the real reason why it is slow.
On 2009-04-30, Matthew Dempsky wrote:
> On Thu, Apr 30, 2009 at 4:03 PM, Ariane van der Steldt
> wrote:
>>> - 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 someth
> > I think the crypto framework still
> > does too many context switches for small operations. IIRC It also
> > doesn't do much load balancing when you have multiple accelerators in
> > the system.
>
> I'm not too interested in accelerator cards at this point, just
> software implementations (i.
On Thu, Apr 30, 2009 at 5:24 PM, Ariane van der Steldt wrote:
> I think if you are going to differentiate on that level, you'll not get
> it in the kernel.
That's fine. This is a personal project primarily intended for my own
benefit in learning more about hacking on the kernel. If it actually
On Thu, Apr 30, 2009 at 04:52:59PM -0700, Matthew Dempsky wrote:
> On Thu, Apr 30, 2009 at 4:03 PM, Ariane van der Steldt
> wrote:
> >> ? - 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
On Thu, Apr 30, 2009 at 4:03 PM, Ariane van der Steldt
wrote:
>> - 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 thin
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/crypt
On Thu, Apr 30, 2009 at 11:53 AM, Ted Unangst wrote:
> All your plans address making the crypto code faster, but I'm not sure
> that's actually the slow point.
That's possible, hence the first step of benchmarking to see if it
helps at all. If not, I'll take a stab at improving something else
fi
On Thu, Apr 30, 2009 at 2:29 PM, Matthew Dempsky wrote:
> I've been thinking of playing with improving the speed of OpenBSD's
> cryptography primitives. My tentative plans:
> 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 p
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
20 matches
Mail list logo
