On Wed, May 9, 2018 at 5:56 PM, Assaf Gordon wrote:
> This echoes back to Bruno's suggestion of runtime parsing of
> /proc/crypto - which adds more complexity.
>
That's very difficult, as entries will appear in /proc only after a module load
>
> For example if this change is endorsed by Redhat,
Hello Matteo and all,
Let me emphasize that I'm not against this feature, but I just think it
should be disabled by default, and enabled explicitly with a "configure"
flag when downstream users want it and deemed it worthwhile.
On 09/05/18 02:57 AM, Matteo Croce wrote:
[...]
All this kernel sup
On Wed, May 9, 2018 at 9:29 AM, Paul Eggert 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
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?
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
Hi Matteo,
> I see the same for PPC64 and S390X, in the time being I'll borrow two
> machines and provide tests on them.
When you test these, please can you also report the 'priority' that
/proc/crypto shows for these algorithms? I'm trying to find a reasonable
'priority' threshold for the afalg_
On Tue, May 8, 2018 at 3:25 AM, Assaf Gordon wrote:
> A comment about the above:
> Talking about "crypto API" lumps together encryption (e.g. AES) and hashing.
> The link [3] talks about the "AES-NI" which is used for encryption
> (and from personal anecdotal evidence indeed provide nice speedups
On Tue, May 8, 2018 at 1:10 AM, Bruno Haible wrote:
> Hi all,
>
> Thanks for your benchmarking help and explanations.
>
> Let me try to summarize.
>
> * We need to consider each of the algorithms md5, sha1 sha256 separately,
> because each algorithm has a different performance characteristi
Hello,
On Tue, May 08, 2018 at 02:20:07AM +0200, Bruno Haible wrote:
> The following approaches come to mind:
[...]
> * Use the kernel-provided meta-info about the algorithms to decide whether
> to use the kernel API.
>
> In detail: Read /proc/crypto at run time. It consists of records
Hello Bruno and all,
On Tue, May 08, 2018 at 01:10:52AM +0200, Bruno Haible wrote:
> Let me try to summarize.
Thanks for writing this - informative and helpful.
> * We need to consider each of the algorithms md5, sha1 sha256 separately,
> because each algorithm has a different performanc
On 05/07/2018 05:20 PM, Bruno Haible wrote:
* Use the kernel-provided meta-info about the algorithms to decide whether
to use the kernel API.
...
Drawback: Does not work if /proc is not mounted.
I would favour the third approach.
I agree. With the Linux kernel these days, mountin
What can we do to get the speedups but avoid the slowdowns, in the two
hairy cases
- the afalg_buffer case,
- the afalg_stream case with non-regular files?
The following approaches come to mind:
* A "tuning" framework like the one from GMP. This is a set of benchmark
programs that the d
11 matches
Mail list logo
