> -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@xxxxxxxxxx] > Sent: Friday, May 24, 2019 11:45 AM > To: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxxxx> > Cc: Christophe Leroy <christophe.leroy@xxxxxx>; linux-crypto@xxxxxxxxxxxxxxx > Subject: Re: another testmgr question > > On Fri, 24 May 2019 at 11:34, Pascal Van Leeuwen > <pvanleeuwen@xxxxxxxxxxxxxxxx> wrote: > > > > > All userland clients of the in-kernel crypto use it specifically to > > > access h/w accelerators, given that software crypto doesn't require > > > the higher privilege level (no point in issuing those AES CPU > > > instructions from the kernel if you can issue them in your program > > > directly) > > > > > > Basically, what is used is a socket interface that can block on > > > read()/write(). So the userspace program doesn't need to be aware of > > > the asynchronous nature, it is just frozen while the calls are being > > > handled by the hardware. > > > > > With all due respect, but if the userland application is indeed > > *frozen* while the calls are being handled, then that seems like its > > pretty useless - for symmetric crypto, anyway - as performance would be > > dominated by latency, not throughput. > > Hardware acceleration would almost always lose that compared to a local > > software implementation. > > I certainly wouldn't want such an operation to end up at my driver! > > > > 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; > - 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 > 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. In addition to the assumption that using the hardware will actually *achieve* this, while that really depends on the ratio of driver overhead (which can be quite significant, unfortunately, especially if the API was not really created from the get-go with HW in mind) vs hardware processing time. 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. Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Inside Secure www.insidesecure.com
