Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <AM6PR09MB3523CED0B1587FCBDE4095A0D2010@AM6PR09MB3523.eurprd09.prod.outlook.com>
 <20190523185833.GA243994@google.com> <AM6PR09MB3523749B0306103E8D2D8315D2010@AM6PR09MB3523.eurprd09.prod.outlook.com>
 <20190523200557.GA248378@gmail.com> <AM6PR09MB3523DB255516D35B595AEA50D2010@AM6PR09MB3523.eurprd09.prod.outlook.com>
 <20190523234853.GC248378@gmail.com> <AM6PR09MB3523CFCFE42A33621FE4ACC3D2020@AM6PR09MB3523.eurprd09.prod.outlook.com>
 <907eb6a5-dc76-d5ee-eccf-e7bd426a0868@c-s.fr> <AM6PR09MB3523D9D6D249701D020A3D74D2020@AM6PR09MB3523.eurprd09.prod.outlook.com>
 <CAKv+Gu_Pxv97rpt7Ju0EdtFnXqp3zoYfHtm1Q51oJSGEAZmyDA@mail.gmail.com>
 <AM6PR09MB3523A8A4BEDDF2B59A7B9A09D2020@AM6PR09MB3523.eurprd09.prod.outlook.com>
 <CAKv+Gu-4c-zoRfMyL8wjQWO2BWNBR=Q8o3=CjNDarNcda-DvFQ@mail.gmail.com> <AM6PR09MB35232C98F70FCB4A37AE7148D2020@AM6PR09MB3523.eurprd09.prod.outlook.com>
In-Reply-To: <AM6PR09MB35232C98F70FCB4A37AE7148D2020@AM6PR09MB3523.eurprd09.prod.outlook.com>
From:   Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Fri, 24 May 2019 13:09:35 +0200
Message-ID: <CAKv+Gu-iPWA8i9f9SYkoG4SJYUv93PBo6ozMqBA7nGegUVm5gQ@mail.gmail.com>
Subject: Re: another testmgr question
To:     Pascal Van Leeuwen <pvanleeuwen@insidesecure.com>
Cc:     Christophe Leroy <christophe.leroy@c-s.fr>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Fri, 24 May 2019 at 11:57, Pascal Van Leeuwen
<pvanleeuwen@insidesecure.com> wrote:
>
> > 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".
>

It becomes even more complicated to reason about if you take into
account that you may have 10s or 100s of instances of the CPU crypto
logic (one for each CPU) while the number of h/w IP blocks and/or
parallel processing queues typically doesn't scale in the same way.

But we are going down a rabbit hole here: even if you and I would
agree that it never makes any sense whatsoever to use h/w accelerators
from userland, the reality is that this is happening today, and so we
have to ensure that all drivers expose an interface that produces the
correct result for all imaginable corner cases.

> > - 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.
>

Evidently, it requires some care to use the AF_ALG interface
meaningfully. But that does not mean it cannot ever be used in the
right way.