> Again, you are making assumptions here that don't always hold. Note that > - a frozen process frees up the CPU to do other things while the > crypto is in progress; > - h/w crypto is typically more power efficient than CPU crypto; > True. Those are the "other" reasons - besides acceleration - to use hardware offload which we often use to sell our IP. But the honest story there is that that only works out for situations where there's enough work to do to make the software overhead for actually starting and managing that work insignificant. And even then, it's only a valid use case if that is your *intention*. If you *just* needed the highest performance, you don't want to go through the HW in this case (unless you have a *very* weak CPU perhaps, or a huge amount of data to process in one go). The catch is in the "always". But how do you make an informed decision here? The current Crypto API does not really seem to provide a mechanism for doing so. In which case MY approach would be "if I'm not SURE that the HW can do it better, then I probably shouldn't be doing in on the HW". > - several userland programs and in-kernel users may be active at the > same time, so the fact that a single user sleeps doesn't mean the > hardware is used inefficiently > I'm not worried about the *HW* being used inefficiently. I'm worried about using the HW not being an improvement. Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Inside Secure www.insidesecure.com
