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 > Which brings up a question: is there some way for a driver to indicate > something like "don't use me unless you can seriously pipeline your > requests"? > > Regards, > Pascal van Leeuwen > Silicon IP Architect, Multi-Protocol Engines @ Inside Secure > www.insidesecure.com >
