lkml.org 
[lkml]   [2015]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions optimized SHA1 & SHA256
From
Date
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




\
 
 \ /
  Last update: 2015-09-11 02:21    [W:0.072 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site