> -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@xxxxxxxxxx] > Sent: Friday, May 24, 2019 1:10 PM > 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:57, Pascal Van Leeuwen > <pvanleeuwen@xxxxxxxxxxxxxxxx> wrote: > > > > > 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; > > > > > True. Those are the "other" reasons - besides acceleration - to use > hardware > > offload which we often use to sell our IP. > > But the honest story there is that that only works out for situations > > where there's enough work to do to make the software overhead for actually > > starting and managing that work insignificant. > > > > And even then, it's only a valid use case if that is your *intention*. > > If you *just* needed the highest performance, you don't want to go through > > the HW in this case (unless you have a *very* weak CPU perhaps, or a > > huge amount of data to process in one go). > > > > The catch is in the "always". But how do you make an informed decision > > here? The current Crypto API does not really seem to provide a mechanism > > for doing so. In which case MY approach would be "if I'm not SURE that > > the HW can do it better, then I probably shouldn't be doing in on the HW". > > > > It becomes even more complicated to reason about if you take into > account that you may have 10s or 100s of instances of the CPU crypto > logic (one for each CPU) while the number of h/w IP blocks and/or > parallel processing queues typically doesn't scale in the same way. > > But we are going down a rabbit hole here: even if you and I would > agree that it never makes any sense whatsoever to use h/w accelerators > from userland, the reality is that this is happening today, and so we > have to ensure that all drivers expose an interface that produces the > correct result for all imaginable corner cases. > > > > - 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 > > > > > I'm not worried about the *HW* being used inefficiently. > > I'm worried about using the HW not being an improvement. > > > > Evidently, it requires some care to use the AF_ALG interface > meaningfully. But that does not mean it cannot ever be used in the > right way. > I think we agree on the big picture. As I already argued in a different thread, the best approach is probably to not select the hardware by default at all, but make it an explicit choice. I suppose that could be achieved within the current framework by just giving all hardware drivers a low cra_priority figure. Thing is, that requires providing some confidence to hardware vendors that ALL crypto consumers will indeed provide some configuration option to select the driver explicitly. In which case hardware vendors could simply recommend using their driver for certain applications that have been tested and known to be usefully accelerated (or achieve lower power consumption or lower CPU load, whatever is your specific requirement). Or to NOT use their drivers for certain applications that don't benefit. Another psychological barrier, though, is that cra_priority can be perceived as some indication of how "good" the hardware is. And obviously no hardware vendor would want to make his/her hardware look worse than the competion. Or worse than software implementations for that matter. Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Inside Secure www.insidesecure.com
