> -----Original Message----- > From: [email protected] <[email protected]> > On Behalf > Of Pascal Van Leeuwen > Sent: Friday, September 27, 2019 12:44 PM > To: Linus Torvalds <[email protected]> > Cc: Ard Biesheuvel <[email protected]>; Linux Crypto Mailing List > <linux- > [email protected]>; Linux ARM <[email protected]>; > Herbert Xu > <[email protected]>; David Miller <[email protected]>; Greg KH > <[email protected]>; Jason A . Donenfeld <[email protected]>; Samuel > Neves > <[email protected]>; Dan Carpenter <[email protected]>; Arnd Bergmann > <[email protected]>; Eric Biggers <[email protected]>; Andy Lutomirski > <[email protected]>; > Will Deacon <[email protected]>; Marc Zyngier <[email protected]>; Catalin Marinas > <[email protected]> > Subject: RE: [RFC PATCH 18/18] net: wireguard - switch to crypto API for > packet > encryption > > > -----Original Message----- > > From: Linus Torvalds <[email protected]> > > Sent: Friday, September 27, 2019 4:54 AM > > To: Pascal Van Leeuwen <[email protected]> > > Cc: Ard Biesheuvel <[email protected]>; Linux Crypto Mailing List > > <linux- > > [email protected]>; Linux ARM <[email protected]>; > > Herbert Xu > > <[email protected]>; David Miller <[email protected]>; Greg KH > > <[email protected]>; Jason A . Donenfeld <[email protected]>; Samuel > > Neves > > <[email protected]>; Dan Carpenter <[email protected]>; Arnd Bergmann > > <[email protected]>; Eric Biggers <[email protected]>; Andy Lutomirski > <[email protected]>; > > Will Deacon <[email protected]>; Marc Zyngier <[email protected]>; Catalin > > Marinas > > <[email protected]> > > 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 > > <[email protected]> wrote: > > > > > > 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. > > Never mind. From what I just learned, you can achieve the same thing with the skcipher API by just requesting a sync implementation. Which would allow you to put your structs on the stack and would not return from the encrypt()/decrypt() call until actually done.
Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
