bug-gnulib
[Top][All Lists]
Advanced

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

Re: [PATCH 0/4] Use AF_ALG in checksum utilities


From: Matteo Croce
Subject: Re: [PATCH 0/4] Use AF_ALG in checksum utilities
Date: Tue, 24 Apr 2018 12:42:54 +0200

On Mon, Apr 23, 2018 at 7:18 PM, Bruno Haible <address@hidden> wrote:
> Hi Matteo,
>
>> >   * <https://en.wikipedia.org/wiki/Crypto_API_(Linux)> says that on x86
>> >     platforms the same functions can be done through CPU instructions. Are 
>> > these
>> >     instructions privileged? If not, then what are - for this frequent 
>> > case of
>> >     Intel CPUs - the advantages and tradeoffs of user-space vs. 
>> > kernel-space
>> >     use of this crypto instructions?
>> >
>>
>> the istructions run unpriviledged. The advantage of the kernel-space
>> crypto is that if an HW crypto engine is available, the kernel will
>> use it.
>> Another advantage is that for file smaller than 2G it can be done via
>> a single sendfile() call, instead of reading blocks of 32 kb as usual.
>> And, as a third advantage, less runtime dependencies, the binary
>> doesn't depend on libcrypto, libz, libdl and libpthread. Some
>> distribution like Debian avoid linking on libcrypto for licensing
>> reason, so af_alg is the only way to get faster code than the builtin
>> one.
>
> Good. And the drawbacks of the kernel approach:
>   - The system call overhead is probably negligible.
>   - Is there some kernel lock that would prevent simultaneous execution of
>     crypto primitives by different threads or processes?
>

If not using an HW crypto engine, the code doesn't have locks, but I
tried it anyway on a quad core machine:

$ time ./sha1sum 2g.bin
752ef2367f479e79e4f0cded9c270c2890506ab0  2g.bin

real    0m2.198s
user    0m0.000s
sys     0m2.198s
$ for i in {1..4}; do time ./sha1sum 2g.bin & done
[1] 27893
[2] 27894
[3] 27896
[4] 27897
752ef2367f479e79e4f0cded9c270c2890506ab0  2g.bin

real    0m2.367s
user    0m0.001s
sys     0m2.367s
752ef2367f479e79e4f0cded9c270c2890506ab0  2g.bin

real    0m2.374s
user    0m0.000s
sys     0m2.365s
752ef2367f479e79e4f0cded9c270c2890506ab0  2g.bin

real    0m2.383s
user    0m0.001s
sys     0m2.383s
752ef2367f479e79e4f0cded9c270c2890506ab0  2g.bin

real    0m2.383s
user    0m0.001s
sys     0m2.382s

[1]   Done                    time ./sha1sum 2g.bin
[2]   Done                    time ./sha1sum 2g.bin
[3]-  Done                    time ./sha1sum 2g.bin
[4]+  Done                    time ./sha1sum 2g.bin

If you're using an HW crypto engine, locking can happen depending on
how the hardware works, but such chips can be 100x faster than CPUs so
it's not an issue.

-- 
Matteo Croce
per aspera ad upstream



reply via email to

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