-----Original Message-----
From: Linus Torvalds <torvalds@linux-foundation.org>
Sent: Friday, September 27, 2019 4:54 AM
To: Pascal Van Leeuwen <redacted>
Cc: Ard Biesheuvel <redacted>; Linux Crypto Mailing List <linux-
crypto@vger.kernel.org>; Linux ARM [off-list ref]; Herbert Xu
[off-list ref]; David Miller [off-list ref]; Greg KH
[off-list ref]; Jason A . Donenfeld [off-list ref]; Samuel Neves
[off-list ref]; Dan Carpenter [off-list ref]; Arnd Bergmann
[off-list ref]; Eric Biggers [off-list ref]; Andy Lutomirski [off-list ref];
Will Deacon [off-list ref]; Marc Zyngier [off-list ref]; Catalin Marinas
[off-list ref]
Subject: Re: [RFC PATCH 18/18] net: wireguard - switch to crypto API for packet
encryption

On Thu, Sep 26, 2019 at 6:30 PM Linus Torvalds
[off-list ref] wrote:

quoted

And once you have that cookie, and you see "ok, I didn't get the
answer immediately" only THEN do you start filling in things like
callback stuff, or maybe you set up a wait-queue and start waiting for
it, or whatever".

Side note: almost nobody does this.

Almost every single async interface I've ever seen ends up being "only
designed for async".

And I think the reason is that everybody first does the simply
synchronous interfaces, and people start using those, and a lot of
people are perfectly happy with them. They are simple, and they work
fine for the huge majority of users.

And then somebody comes along and says "no, _we_ need to do this
asynchronously", and by definition that person does *not* care for the
synchronous case, since that interface already existed and was simpler
and already was mostly sufficient for the people who used it, and so
the async interface ends up being _only_ designed for the new async
workflow. Because that whole new world was written with just that case
is mind, and the synchronous case clearly didn't matter.

So then you end up with that kind of dichotomous situation, where you
have a strict black-and-white either-synchronous-or-async model.

And then some people - quite reasonably - just want the simplicity of
the synchronous code and it performs better for them because the
interfaces are simpler and better suited to their lack of extra work.

And other people feel they need the async code, because they can take
advantage of it.

And never the twain shall meet, because the async interface is
actively _bad_ for the people who have sync workloads and the sync
interface doesn't work for the async people.

Non-crypto example: [p]read() vs aio_read(). They do the same thing
(on a high level) apart from that sync/async issue. And there's no way
to get the best of both worlds.

Doing aio_read() on something that is already cached is actively much
worse than just doing a synchronous read() of cached data.

But aio_read() _can_ be much better if you know your workload doesn't
cache well and read() blocks too much for you.

There's no "read_potentially_async()" interface that just does the
synchronous read for any cached portion of the data, and then delays
just the IO parts and returns a "here, I gave you X bytes right now,
use this cookie to wait for the rest".

Maybe nobody would use it. But it really should be possibly to have
interfaces where a good synchronous implementation is _possible_
without the extra overhead, while also allowing async implementations.

That's the question. I've never seen such an API yet ...

You could also just accept that those are two wildly different use 
cases with wildly different requirements and allow them to coexist,
while  sharing as much of the low-level SW implementation code as
possible underneath. With the async API only used for those cases
where HW acceleration can make the difference.

I believe for hashes, the Crypto API still maintains an shash and
an ahash API. It works the other way around from how you would
like  to see though, with ahash wrapping the shash in case of SW 
implementations. Still, if you're sure you can't benefit from HW 
acceleration you have the option of using the shash directly.

I don't know why the synchronous blkcipher API was deprecated,
that happened before I joined. IMHO it would make sense to have,
so users not interested in HW crypto are not burdened by it.

                Linus

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel