Messages in this thread | | | Subject | Re: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions optimized SHA1 & SHA256 | From | Tim Chen <> | Date | Thu, 10 Sep 2015 17:04:31 -0700 |
| |
On Fri, 2015-09-11 at 00:52 +0200, Stephan Mueller wrote: > Am Donnerstag, 10. September 2015, 15:27:20 schrieb Tim Chen: > > Hi Tim, > > >This patch adds the glue code to detect and utilize the Intel SHA > >extensions optimized SHA1 and SHA256 update transforms when available. > > > >This code has been tested on Broxton for functionality. > > A general comment on this file: shouldn't this file be cleaned and use the > standard mechanisms of the kernel crypto API? > > This glue implements its own selection of which SHA implementation to use. But > the kernel crypto API implements that logic already. The issue with the > current implementation in this file is that you have no clue which particular > implementation of SHA is in use in one particular case. > > So, may I suggest a restructuring to define independent instances of SHA, such > as > > - cra_name == "sha1", cra_driver_name="sha1_ssse3", cra_priority=300 > - cra_name == "sha1", cra_driver_name="sha1_avx", cra_priority=400 > - cra_name == "sha1", cra_driver_name="sha1_avx2", cra_priority=500 > - cra_name == "sha1", cra_driver_name="sha1_shavx", cra_priority=600 > > Similarly for the other SHAs? > > In all the register functions for the ciphers, you can bail out if the > hardware does not support an implementation.
Stephen,
Is there a scenario you can think of when a lower performing sha1 transform needs to be exposed as a separate driver?
Otherwise the glue code logic will only expose the best performing one for a cpu and hide the others, which was intentional on our part to prevent a lower performing sha from getting used.
Tim
| |