AES Crypto Support in Kernel

Shirish S Pargaonkar shirishp at us.ibm.com
Mon May 6 10:56:35 MDT 2013



Steve French <smfrench at gmail.com> wrote on 05/06/2013 09:11:28 AM:

> From:
>
> Steve French <smfrench at gmail.com>
>
> To:
>
> Shirish S Pargaonkar/Austin/IBM at IBMUS
>
> Cc:
>
> Jeff Layton <jlayton at redhat.com>, Pavel Shilovsky
> <piastryyy at gmail.com>, linux-cifs at vger.kernel.org, samba-technical
> <samba-technical at lists.samba.org>
>
> Date:
>
> 05/06/2013 09:13 AM
>
> Subject:
>
> AES Crypto Support in Kernel
>
> Shirish,
> Does the recent crypto merge to kernel, which includes these two
> patches for example, help you (at least on the more common chips,
> those with optimized AES offload support)?  Wonder if we can leverage
> the hardware offload in Samba?
>
> commit c456a9cd1ac4eae9147ffd7ac4fb77ca0fa980c6
> Author: Jussi Kivilinna <jussi.kivilinna at iki.fi>
> Date:   Mon Apr 8 21:51:16 2013 +0300
>
>     crypto: aesni_intel - add more optimized XTS mode for x86-64
>
>     Add more optimized XTS code for aesni_intel in 64-bit mode, for
> smaller stack
>     usage and boost for speed.
>
>     tcrypt results, with Intel i5-2450M:
>     256-bit key
>             enc     dec
>     16B     0.98x   0.99x
>     64B     0.64x   0.63x
>     256B    1.29x   1.32x
>     1024B   1.54x   1.58x
>     8192B   1.57x   1.60x
> --
>     performance is reduced in tcrypt for 64 byte long blocks.
>
>     Cc: Huang Ying <ying.huang at intel.com>
>     Signed-off-by: Jussi Kivilinna <jussi.kivilinna at iki.fi>
>     Signed-off-by: Herbert Xu <herbert at gondor.apana.org.au>
>
> commit b5c5b072dc2f35d45d3404b957e264a3e8e71069
> Author: Jussi Kivilinna <jussi.kivilinna at iki.fi>
> Date:   Mon Apr 8 21:51:11 2013 +0300
>
>     crypto: x86/camellia-aesni-avx - add more optimized XTS code
>
>     Add more optimized XTS code for camellia-aesni-avx, for smaller
> stack usage
>     and small boost for speed.
>
>     tcrypt results, with Intel i5-2450M:
>             enc     dec
>     16B     1.10x   1.01x
>     64B     0.82x   0.77x
>     256B    1.14x   1.10x
>     1024B   1.17x   1.16x
>     8192B   1.10x   1.11x
>
> --
>     Signed-off-by: Jussi Kivilinna <jussi.kivilinna at iki.fi>
>     Signed-off-by: Herbert Xu <herbert at gondor.apana.org.au>
>
>
> On Mon, May 6, 2013 at 9:00 AM, Shirish S Pargaonkar
> <shirishp at us.ibm.com> wrote:
> >
> > Steve, I am using Herbert Xu 3.8 git repository which has the code.
> >
> > Regards,
> >
> > Shirish
> >
> > Steve French ---05/05/2013 10:43:10 PM---Sounds great.  Has the
> new aes cmac lib been added to kernel yet in 3.10? On May 5, 2013 10:33
PM, "
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
> --
> Thanks,
>
> Steve
>

Steve, Jeff,

I am not sure how all this comes together.

Currently cifs client uses kernel crypto code during authentication
and signing (signature generation), mostly for NTLMSSP.

So I am not sure how and where Samba comes into picture.
Would we want to change from using kernel cryto code to either code
within Samba (which APIs?) or the code that Samba uses (NSS libs (APIs?))
and if so, would that mean making kernel upcalls?

And then what kind of hardware do we need to measure the performance
(improvment) and how do we measure the performacne (improvment).

Not sure what all Samba crypto code has or the NSS libs have but I
would think it has all the hash generating functions that cifs client
needs include CMAC-AES!

Regards,

Shirish


More information about the samba-technical mailing list