> -----Original Message----- > From: linux-crypto-ow...@vger.kernel.org <linux-crypto-ow...@vger.kernel.org> > On Behalf > Of Pascal Van Leeuwen > Sent: Friday, September 27, 2019 12:44 PM > To: Linus Torvalds <torva...@linux-foundation.org> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Linux Crypto Mailing List > <linux- > cry...@vger.kernel.org>; Linux ARM <linux-arm-ker...@lists.infradead.org>; > Herbert Xu > <herb...@gondor.apana.org.au>; David Miller <da...@davemloft.net>; Greg KH > <gre...@linuxfoundation.org>; Jason A . Donenfeld <ja...@zx2c4.com>; Samuel > Neves > <sne...@dei.uc.pt>; Dan Carpenter <dan.carpen...@oracle.com>; Arnd Bergmann > <a...@arndb.de>; Eric Biggers <ebigg...@google.com>; Andy Lutomirski > <l...@kernel.org>; > Will Deacon <w...@kernel.org>; Marc Zyngier <m...@kernel.org>; Catalin Marinas > <catalin.mari...@arm.com> > Subject: RE: [RFC PATCH 18/18] net: wireguard - switch to crypto API for > packet > encryption > > > -----Original Message----- > > From: Linus Torvalds <torva...@linux-foundation.org> > > Sent: Friday, September 27, 2019 4:54 AM > > To: Pascal Van Leeuwen <pvanleeu...@verimatrix.com> > > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Linux Crypto Mailing List > > <linux- > > cry...@vger.kernel.org>; Linux ARM <linux-arm-ker...@lists.infradead.org>; > > Herbert Xu > > <herb...@gondor.apana.org.au>; David Miller <da...@davemloft.net>; Greg KH > > <gre...@linuxfoundation.org>; Jason A . Donenfeld <ja...@zx2c4.com>; Samuel > > Neves > > <sne...@dei.uc.pt>; Dan Carpenter <dan.carpen...@oracle.com>; Arnd Bergmann > > <a...@arndb.de>; Eric Biggers <ebigg...@google.com>; Andy Lutomirski > <l...@kernel.org>; > > Will Deacon <w...@kernel.org>; Marc Zyngier <m...@kernel.org>; Catalin > > Marinas > > <catalin.mari...@arm.com> > > 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 > > <torva...@linux-foundation.org> 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
