* Herbert Xu | 2008-08-07 22:53:12 [+0800]:

>I've coded this up with the per-cpu structure and it seems to work.
yup, excellent. Thanks for finishing this. I had the following comment
above my DEFINE_PER_CPU definition (I replaced my definition with
last_cword):
|/*
| * PER-CPU last_cword is here to make this code SMP / future safe and works as
| * follows: After every crypt operation, the CPU sets EFLAGS:30 to indicate
| * that the key is already in the CPU and catch-the-key-from-memory operation
| * can be saved. This bit needs to be cleared if we change the key. This bit is
| * auto-cleared by the CPU on every context switch (and can not be set by the
| * kernel). We don't lock our self to one CPU during the crypt process because
| * it isn't required: If we get scheduled to another CPU after the var check
| * and before the crypt operation than the CPU clears the EFLAGS:30 bit and the
| * CPU reloads the key anyway. The same things happens if we get scheduled to
| * another CPU after the crypt operation but before we set last_cword.
| */

I had a few missing pieces and was never was in the mode to finish it.

>It doesn't make much of a difference for ECB/CBC but with LRW/XTS
>it gives a huge boost.
Well, the spec says the key reload takes a lot of time so it should give
a big boost to everything what isn't supported directly in HW.
The padlock supports a few other modes like OFB but I doubt they are
required since they aren't even implemented in SW.

>Cheers,

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to