bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: af_alg benchmarks and performance


From: Matteo Croce
Subject: Re: af_alg benchmarks and performance
Date: Wed, 9 May 2018 10:57:45 +0200

On Wed, May 9, 2018 at 9:29 AM, Paul Eggert <address@hidden> wrote:
>> Fortunately other non deprecated algos like sha256 are way
>> faster.
>
>
> Faster than when --with-openssl is used? Can you show me how to benchmark
> that?
>

Faster than the C code. The performance of af_alg and openssl are
comparable, they can range from slighty faster, to slighty slower
depending on the CPU:

arm64
$ time ./sha256sum-afalg ubuntu-18.04-desktop-amd64.iso
a55353d837cbf7bc006cf49eeff05ae5044e757498e30643a9199b9a25bc9a34
ubuntu-18.04-desktop-amd64.iso

real    0m2.305s
user    0m0.000s
sys     0m2.305s

$ time ./sha256sum-libcrypto ubuntu-18.04-desktop-amd64.iso
a55353d837cbf7bc006cf49eeff05ae5044e757498e30643a9199b9a25bc9a34
ubuntu-18.04-desktop-amd64.iso

real    0m2.454s
user    0m1.993s
sys     0m0.461s


x86_64

$ time ./sha256sum-afalg ubuntu-18.04-desktop-amd64.iso
a55353d837cbf7bc006cf49eeff05ae5044e757498e30643a9199b9a25bc9a34
ubuntu-18.04-desktop-amd64.iso

real    0m3,706s
user    0m0,000s
sys     0m3,704s
$ time ./sha256sum-libcrypto ubuntu-18.04-desktop-amd64.iso
a55353d837cbf7bc006cf49eeff05ae5044e757498e30643a9199b9a25bc9a34
ubuntu-18.04-desktop-amd64.iso

real    0m3,404s
user    0m3,273s
sys     0m0,119s

All this kernel support was not meant to replace openssl, it's more
likely an alternative. There are already two cases I care about
when this can be used while openssl can't
- Debian doesn't links coreutils against libssl for legal issues
- In embedded devices like the ones supported by OpenWrt, having 2 MB
  of libcrypto is not acceptable, expecially when the kernel has the
  code already

> After reading Assaf's comments I confess that I'm not getting the point of
> the recent changes. As I understand it, the hardware support in question is
> typically available to user-mode code so why go to the kernel at all? And
> even if there are magic features not available outside the kernel, why not
> let the OpenSSL library worry about the tradeoffs involved in user vs kernel
> mode rather than reinvent its wheel? It's a real pain to ship data off to
> the kernel with all the overheads and other hassles involved, and I don't
> see why it's a good idea for Gnulib to get involved.
>
> At this point I am leaning towards reverting these changes. If we keep them,
> the default should be to disable this new feature; plus, several bugs (at
> least one of which I introduced; sorry!) need to be fixed. I'm not sure it's
> worth the maintenance effort to keep this stuff in, at least if it's
> coreutils we're talking about.

What do you mean for HW support? If you are referring to instructions
like Intel SSSE3/AVX, they are available for userspace too.
But for real HW support, like dedicated chips, you can't access them
directly from the HW.

As example, here there is an arm64 board[1] which have an HW crypto engine from
SafeNet. Looking in /proc/crypto reveals that the algos are using it

# grep 'sha1$' -m1 -A9 /proc/crypto
driver       : safexcel-hmac-sha1
module       : crypto_safexcel
priority     : 300
refcnt       : 1
selftest     : passed
internal     : no
type         : ahash
async        : yes
blocksize    : 64
digestsize   : 20

# grep 'sha256$' -m1 -A9 /proc/crypto
driver       : safexcel-hmac-sha256
module       : crypto_safexcel
priority     : 300
refcnt       : 1
selftest     : passed
internal     : no
type         : ahash
async        : yes
blocksize    : 64
digestsize   : 32

# modinfo crypto_safexcel
filename:
/lib/modules/4.14.22/kernel/drivers/crypto/inside-secure/crypto_safexcel.ko
license:        GPL v2
description:    Support for SafeXcel cryptographic engine EIP197

Other devices like PC Engines ALIX have a similar HW and it's already
supported by the kernel.

Also, on cloud installations, where servers are VMs running under an
hypervisor, there could be an HW crypto in the hypervisor itself
shared between the guests, and the kernel has already a virtio crypto
driver to access transparently the HW of the host[2]

So if you concern is about bad performances in common use cases, you
can disable it by default and package maintainers or firmware
developers can enable it as needed.

[1] http://macchiatobin.net/product/macchiatobin-double-shot/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/crypto/virtio

-- 
Matteo Croce
per aspera ad upstream



reply via email to

[Prev in Thread] Current Thread [Next in Thread]