> > 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. > > > > I never said power consumption is *always* more important. You were > assuming it never is. > Nooooo I wasn't. Not on purpose, anyway. Power consumption is a major selling point for us. If you got that impression, then that's some misunderstanding. My argument was simply that there *may* be other requirements. You don't know, so you shouldn't make assumptions in the other direction either. > > 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. > > > > True. But we have already painted ourselves into a corner here, since > whatever we expose to userland today cannot simply be revoked. > > I guess you could argue that your particular driver should not be > exposed to userland, and I think we may even have a CRYPTO_ALG_xxx > Well, I understood from someone else on this list that CRYPTO_ALG can do async operations in which case I would assume it doesn't block?? I would rather see a flag denoting "do not use me in a synchronous fashion on relatively small datablocks, only use me if you intend to seriously pipeline your requests". Or somesuch. But then again that would still be too simplistic to select to best driver under all possible circumstances ... so why even bother. > flag for that. But even if that does happen, it doesn't mean you can > stop caring about zero length inputs :-) > If the selection of the hardware driver becomes explicit and not automatic, you could argue for a case where the driver does NOT have to implement all dark corners of the API. As, as a hardware vendor, we could simply recommend NOT to use it for application XYZ because it does things - like zero length messages - we don't support. Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Inside Secure www.insidesecure.com
