RE: another testmgr question

[Pascal Van Leeuwen <pvanleeuwen@insidesecure.com>]

> 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