Thread (9 messages) 9 messages, 4 authors, 2015-09-12

Re: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions optimized SHA1 & SHA256

flat view

From: Tim Chen <hidden>
Date: 2015-09-11 00:04:33
Also in: lkml

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,
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help