On Tue, 20 Sep 2016, Russell King - ARM Linux wrote:
> each of those places where af_alg_wait_for_completion() called, we
> end up submitting a bunch of data and then immediately waiting for
> the operation to complete... and this can be seen in the perf
> trace logs.
That'd explain it.
> So, un
On Tue, Sep 20, 2016 at 10:10:20PM +0200, Thomas Gleixner wrote:
> On Tue, 20 Sep 2016, Russell King - ARM Linux wrote:
> > which corresponds to an 8% slowdown for the threaded IRQ case. So,
> > tasklets are indeed faster than threaded IRQs.
>
> Fair enough.
>
> > I've tried to perf it, but...
>
On Tue, 20 Sep 2016, Russell King - ARM Linux wrote:
> which corresponds to an 8% slowdown for the threaded IRQ case. So,
> tasklets are indeed faster than threaded IRQs.
Fair enough.
> I've tried to perf it, but...
>
> So, sorry, I'm not going to bother trying to get any further with th
Okay, I've re-tested, using a different way of measuring, because using
openssl speed is impractical for off-loaded engines. I've decided to
use this way to measure the performance:
dd if=/dev/zero bs=1048576 count=128 | /usr/bin/time openssl dgst -md5
For the threaded IRQs case gives:
0.05user
Currently omap-rng checks the return value of pm_runtime_get_sync and
reports failure if anything is returned, however it should be checking
if ret < 0 as pm_runtime_get_sync return 0 on success but also can return
1 if the device was already active which is not a failure case. Only
values < 0 are
On Tue, 2016-09-20 at 20:35 +0800, Herbert Xu wrote:
> On Tue, Sep 20, 2016 at 08:11:51AM -0400, Mimi Zohar wrote:
> > Hi Herbert,
> >
> > The initial random iv value, initialized in encrypted_init(), should
> > not be modified. Commit c3917fd "KEYS: Use skcipher", which replaced
> > the blkciphe
Am Freitag, 19. August 2016, 20:39:09 CEST schrieb Stephan Mueller:
Hi David,
>
> SP800-56A defines the use of DH with key derivation function based on a
> counter. The input to the KDF is defined as (DH shared secret || other
> information). The value for the "other information" is to be provid
On Tue, Sep 20, 2016 at 08:11:51AM -0400, Mimi Zohar wrote:
> Hi Herbert,
>
> The initial random iv value, initialized in encrypted_init(), should
> not be modified. Commit c3917fd "KEYS: Use skcipher", which replaced
> the blkcipher with skcipher, modifies the iv in
> crypto_skcipher_encrypt()/d
Hi Herbert,
apologies for the duplicate. The previous email didn't get delivered to
the ML.
On Tue, Sep 20, 2016 at 05:26:18PM +0800, Herbert Xu wrote:
> Rather than duplicating the scratch buffer handling in every scomp
> algorithm, let's centralize this and put it into scomp.c.
Are you suggesti
Hi Herbert,
The initial random iv value, initialized in encrypted_init(), should
not be modified. Commit c3917fd "KEYS: Use skcipher", which replaced
the blkcipher with skcipher, modifies the iv in
crypto_skcipher_encrypt()/decrypt().
The following example creates an encrypted key, writes the ke
On Tue, Sep 13, 2016 at 01:49:36PM +0100, Giovanni Cabiddu wrote:
>
> + lzo_src_scratches = crypto_scomp_alloc_scratches(LZO_SCRATCH_SIZE);
> + if (!lzo_src_scratches)
> + return -ENOMEM;
Rather than duplicating the scratch buffer handling in every scomp
algorithm, let's centra
11 matches
Mail list logo
