Re: another testmgr question

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On Mon, 27 May 2019 at 12:04, Pascal Van Leeuwen
<pvanleeuwen@insidesecure.com> wrote:
>
> > > With all due respect, but you are making assumptions as well. You are
> > > making the assumption that reducing CPU load and/or reducing power
> > > consumption is *more* important than absolute application performance or
> > > latency. Which is certainly not always the case.
> > >
> >
> > I never said power consumption is *always* more important. You were
> > assuming it never is.
> >
> Nooooo I wasn't. Not on purpose, anyway. Power consumption is a major selling
> point for us. If you got that impression, then that's some misunderstanding.
> My argument was simply that there *may* be other requirements. You don't know,
> so you shouldn't make assumptions in the other direction either.
>

That was basically *my* point. But you're welcome to use it :-)

> > > In many cases where only small amounts of data are processed sequentially,
> > > the hardware will simply lose on all accounts ... So Linus actually did
> > > have a point there. Hardware only wins for specific use cases. It's
> > > important to realize that and not try and use hardware for everything.
> > >
> >
> > True. But we have already painted ourselves into a corner here, since
> > whatever we expose to userland today cannot simply be revoked.
> >
> > I guess you could argue that your particular driver should not be
> > exposed to userland, and I think we may even have a CRYPTO_ALG_xxx
> >
> Well, I understood from someone else on this list that CRYPTO_ALG can
> do async operations in which case I would assume it doesn't block??
>
> I would rather see a flag denoting "do not use me in a synchronous
> fashion on relatively small datablocks, only use me if you intend to
> seriously pipeline your requests". Or somesuch.
>

As I explained before, what appears synchronous to a single userland
process may look very differently from the OS and h/w perspective. But
of course, I take your point that h/w is not faster than the CPU in
the general case, and so care must be taken.

This is made worse by the priority scheme, which does not really
convery information like this.

> But then again that would still be too simplistic to select to best
> driver under all possible circumstances ... so why even bother.
>
> > flag for that. But even if that does happen, it doesn't mean you can
> > stop caring about zero length inputs :-)
> >
> If the selection of the hardware driver becomes explicit and not
> automatic, you could argue for a case where the driver does NOT have
> to implement all dark corners of the API. As, as a hardware vendor,
> we could simply recommend NOT to use it for application XYZ  because
> it does things - like zero length messages - we don't support.
>

Spoken like a true h/w guy :-)

Our crypto s/w stack and the storage, networking and other subsystems
that are layered on top of it are complex enough that we shouldn't try
to cater for non-compliant hardware. This is why you need to fix this
in your driver: to prevent the issue from leaking into other layers,
making it even more difficult to do testing and validation.