On Wed, Nov 02, 2016 at 11:00:00PM +0100, Jason A. Donenfeld wrote:
>
> Just tested. I get a 6% slowdown on my Skylake. No good. I think it's
> probably best to have the two paths in there, and not reduce it to
> one.
FWIW I'd rather live with a 6% slowdown than having two different
code paths in
On Wed, Nov 2, 2016 at 10:26 PM, Herbert Xu wrote:
> What I'm interested in is whether the new code is sufficiently
> close in performance to the old code, particularonly on x86.
>
> I'd much rather only have a single set of code for all architectures.
> After all, this is meant to be a generic im
On Wed, Nov 2, 2016 at 5:25 PM, Jason A. Donenfeld wrote:
> These architectures select HAVE_EFFICIENT_UNALIGNED_ACCESS:
>
> s390 arm arm64 powerpc x86 x86_64
>
> So, these will use the original old code.
>
> The architectures that will thus use the new code are:
>
> alpha arc avr32 blackfin c6x cr
On Wed, Nov 02, 2016 at 10:25:00PM +0100, Jason A. Donenfeld wrote:
> These architectures select HAVE_EFFICIENT_UNALIGNED_ACCESS:
>
> s390 arm arm64 powerpc x86 x86_64
>
> So, these will use the original old code.
What I'm interested in is whether the new code is sufficiently
close in performanc
These architectures select HAVE_EFFICIENT_UNALIGNED_ACCESS:
s390 arm arm64 powerpc x86 x86_64
So, these will use the original old code.
The architectures that will thus use the new code are:
alpha arc avr32 blackfin c6x cris frv h7300 hexagon ia64 m32r m68k
metag microblaze mips mn10300 nios2 o
On Wed, Nov 02, 2016 at 10:06:39PM +0100, Jason A. Donenfeld wrote:
> On Wed, Nov 2, 2016 at 9:09 PM, Herbert Xu
> wrote:
> > Can you give some numbers please? What about other architectures
> > that your patch impacts?
>
> Per [1], the patch gives a 181% speed up on MIPS32r2.
>
> [1] https://l
On Wed, Nov 2, 2016 at 9:09 PM, Herbert Xu wrote:
> Can you give some numbers please? What about other architectures
> that your patch impacts?
Per [1], the patch gives a 181% speed up on MIPS32r2.
[1] https://lists.zx2c4.com/pipermail/wireguard/2016-September/000398.html
--
To unsubscribe from
Hi Herbert, just a few preliminary comments. I haven't made it through
everything yet.
On Wed, Nov 02, 2016 at 07:19:02AM +0800, Herbert Xu wrote:
> +static int skcipher_walk_first(struct skcipher_walk *walk)
> +{
> + if (WARN_ON_ONCE(in_irq()))
> + return -EDEADLK;
> +
> + wa
On Wed, Nov 2, 2016 at 4:09 PM, Herbert Xu wrote:
> On Wed, Nov 02, 2016 at 06:58:10PM +0100, Jason A. Donenfeld wrote:
>> On MIPS chips commonly found in inexpensive routers, this makes a big
>> difference in performance.
>>
>> Signed-off-by: Jason A. Donenfeld
>
> Can you give some numbers ple
On Wed, Nov 02, 2016 at 06:58:10PM +0100, Jason A. Donenfeld wrote:
> On MIPS chips commonly found in inexpensive routers, this makes a big
> difference in performance.
>
> Signed-off-by: Jason A. Donenfeld
Can you give some numbers please? What about other architectures
that your patch impacts?
On MIPS chips commonly found in inexpensive routers, this makes a big
difference in performance.
Signed-off-by: Jason A. Donenfeld
---
crypto/poly1305_generic.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/crypto/poly1305_generic.c b/crypto/po
Move the command queue tail pointer when an error is
detected. Always return the error.
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/ccp-dev-v5.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
i
Switch to resource-managed function devm_kzalloc instead
of kzalloc and remove unneeded kfree
Also, remove kfree in probe function and remove
function, mv_remove as it is now has nothing to do.
The Coccinelle semantic patch used to make this change is as follows:
//
@platform@
identifier p, probef
13 matches
Mail list logo
