Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1223037

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

From Tim Chen <tim.c.chen@linux.intel.com>
Newsgroups linux.kernel
Subject Re: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions optimized SHA1 & SHA256
Date 2015-09-11 20:50 +0200
Message-ID <q7Byx-1CO-5@gated-at.bofh.it> (permalink)
References <q7ivU-6Gg-19@gated-at.bofh.it> <q7iYV-7f3-7@gated-at.bofh.it> <q7k4H-BL-25@gated-at.bofh.it> <q7zZN-7Wu-33@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri, 2015-09-11 at 19:02 +0200, Stephan Mueller wrote:
> Am Donnerstag, 10. September 2015, 17:04:31 schrieb Tim Chen:
> 
> Hi Tim,
> >
> >Is there a scenario you can think of
> >when a lower performing sha1 transform needs to
> >be exposed as a separate driver?
> 
> My immediate concern is testing: it is hard to test the individual 
> implementations.
> >

Not hard, just one line in the glue code to set the transform
to the one you need it you really want to test individual 
implementation.  Usually user of sha don't care which sha driver
they got, but just the highest priority one. 
So you will anyway need to patch and change the priority of the sha
driver to expose a specific one for testing.

> >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.
> 
> Agreed, but the kernel crypto API does that already using the priorities -- 
> IMHO a very clean and easy to interpret solution.
> 
> Furthermore, if somebody really has a need to not use the fastest HW 
> implementation, the kernel crypto API allows him to do that. With the hard-
> wired approach in the glue file, you are stuck.

Still, why would some kernel module specifically not want to 
use the fastest HW implementation, and explicitly ask for
a slower driver?

Tim

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions  optimized SHA1 & SHA256 Tim Chen <tim.c.chen@linux.intel.com> - 2015-09-11 00:30 +0200
  Re: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions optimized SHA1 & SHA256 Stephan Mueller <smueller@chronox.de> - 2015-09-11 01:00 +0200
    Re: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions  optimized SHA1 & SHA256 Tim Chen <tim.c.chen@linux.intel.com> - 2015-09-11 02:10 +0200
      Re: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions optimized SHA1 & SHA256 Stephan Mueller <smueller@chronox.de> - 2015-09-11 19:10 +0200
        Re: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions  optimized SHA1 & SHA256 Tim Chen <tim.c.chen@linux.intel.com> - 2015-09-11 20:50 +0200
          Re: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions optimized SHA1 & SHA256 Stephan Mueller <smueller@chronox.de> - 2015-09-11 21:20 +0200
          Re: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions  optimized SHA1 & SHA256 David Miller <davem@davemloft.net> - 2015-09-11 21:20 +0200
            Re: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions  optimized SHA1 & SHA256 Tim Chen <tim.c.chen@linux.intel.com> - 2015-09-11 22:20 +0200
              Re: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions  optimized SHA1 & SHA256 Herbert Xu <herbert@gondor.apana.org.au> - 2015-09-12 10:20 +0200

csiph-web