Hi, On 4/13/07, Helge Hafting <[EMAIL PROTECTED]> wrote:
Francis Moreau wrote: > So is this interpretation right ? If so wouldn't it be appropriate to > introduce a mechanism to reserve this AES hardware for a special > purpose (filesystem encryptions) and thus make it as fast as possible > ? > Would this really help? When reading/writing files, most of the time is i/o-wait, isn't it?
Well some systems, specially embedded ones, don't use hard drives for mass storage purposes but rather MTD like flashes...
Reserving the device exclusively seems excessive. How about a quick test to see if someone else have been using it since the last time your crypto-fs used it? If nobody else used it, then you don't need to reset they key and so on.
You would spend the same time to make the test as loading the key...
If nobody else is using the AES controller, you get the same speed as with a reservation.
I don't think this is right. AES hardware can do a block encryption in a very few cycles. If you copy the key or test the key to see if it has changed as you proposed, then you basically increase the execution time by a factor 2 or 3...
If something else is using AES then it won't be as fast, but then the AES controller have been used for other useful work as well. Other parts of the kernel surely won't use it just for fun. :-)
You said it: others parts of the kernel are unlikely to use it. So why not optimizing the common case ? Crypto core already seems to implement a priority mechanism. But I don't think I'm able to say "I'd like to use this algo for encrypting filesystems. If another part of the kernel wants to use this algo then give it the generic one". This choice seems really to depend on the system the kernel is running. -- Francis - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
