> 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. > In light of this discussion: I've been pondering about this a lot and I think the best approach would be that the default driver for a certain cipher suite should always be the fastest *software* solution unless the consumer explicitly requests - i.e. because the user configured it to do so - a certain specific (hardware accelerated) implementation. To relieve the burden of selecting a very specific implementation you could consider adding some flag requesting the "best" hardware accelerated implementation, explictly. With the default still being the best software implementation if the flag is not set. The downside of that, though, is that existing Crypto API consumers that do not make the effort to adapt to this scheme never benefit from any hardware acceleration. Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Inside Secure www.insidesecure.com
