* 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
