All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: "Herbert Xu" <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Martin Willi" <martin@strongswan.org>,
	"Eric Biggers" <ebiggers@google.com>,
	"René van Dorst" <opensource@vdorst.com>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
Subject: [PATCH v4] poly1305: generic C can be faster on chips with slow unaligned access
Date: Mon,  7 Nov 2016 20:47:09 +0100	[thread overview]
Message-ID: <20161107194709.20457-1-Jason@zx2c4.com> (raw)
In-Reply-To: <20161107191253.17998-1-Jason@zx2c4.com>

By using the unaligned access helpers, we drastically improve
performance on small MIPS routers that have to go through the exception
fix-up handler for these unaligned accesses.

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
 crypto/poly1305_generic.c | 34 +++++++++++++++-------------------
 1 file changed, 15 insertions(+), 19 deletions(-)

diff --git a/crypto/poly1305_generic.c b/crypto/poly1305_generic.c
index 2df9835d..b1c2d57 100644
--- a/crypto/poly1305_generic.c
+++ b/crypto/poly1305_generic.c
@@ -17,6 +17,7 @@
 #include <linux/crypto.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
+#include <asm/unaligned.h>
 
 static inline u64 mlt(u64 a, u64 b)
 {
@@ -33,11 +34,6 @@ static inline u32 and(u32 v, u32 mask)
 	return v & mask;
 }
 
-static inline u32 le32_to_cpuvp(const void *p)
-{
-	return le32_to_cpup(p);
-}
-
 int crypto_poly1305_init(struct shash_desc *desc)
 {
 	struct poly1305_desc_ctx *dctx = shash_desc_ctx(desc);
@@ -65,19 +61,19 @@ EXPORT_SYMBOL_GPL(crypto_poly1305_setkey);
 static void poly1305_setrkey(struct poly1305_desc_ctx *dctx, const u8 *key)
 {
 	/* r &= 0xffffffc0ffffffc0ffffffc0fffffff */
-	dctx->r[0] = (le32_to_cpuvp(key +  0) >> 0) & 0x3ffffff;
-	dctx->r[1] = (le32_to_cpuvp(key +  3) >> 2) & 0x3ffff03;
-	dctx->r[2] = (le32_to_cpuvp(key +  6) >> 4) & 0x3ffc0ff;
-	dctx->r[3] = (le32_to_cpuvp(key +  9) >> 6) & 0x3f03fff;
-	dctx->r[4] = (le32_to_cpuvp(key + 12) >> 8) & 0x00fffff;
+	dctx->r[0] = (get_unaligned_le32(key +  0) >> 0) & 0x3ffffff;
+	dctx->r[1] = (get_unaligned_le32(key +  3) >> 2) & 0x3ffff03;
+	dctx->r[2] = (get_unaligned_le32(key +  6) >> 4) & 0x3ffc0ff;
+	dctx->r[3] = (get_unaligned_le32(key +  9) >> 6) & 0x3f03fff;
+	dctx->r[4] = (get_unaligned_le32(key + 12) >> 8) & 0x00fffff;
 }
 
 static void poly1305_setskey(struct poly1305_desc_ctx *dctx, const u8 *key)
 {
-	dctx->s[0] = le32_to_cpuvp(key +  0);
-	dctx->s[1] = le32_to_cpuvp(key +  4);
-	dctx->s[2] = le32_to_cpuvp(key +  8);
-	dctx->s[3] = le32_to_cpuvp(key + 12);
+	dctx->s[0] = get_unaligned_le32(key +  0);
+	dctx->s[1] = get_unaligned_le32(key +  4);
+	dctx->s[2] = get_unaligned_le32(key +  8);
+	dctx->s[3] = get_unaligned_le32(key + 12);
 }
 
 unsigned int crypto_poly1305_setdesckey(struct poly1305_desc_ctx *dctx,
@@ -137,11 +133,11 @@ static unsigned int poly1305_blocks(struct poly1305_desc_ctx *dctx,
 	while (likely(srclen >= POLY1305_BLOCK_SIZE)) {
 
 		/* h += m[i] */
-		h0 += (le32_to_cpuvp(src +  0) >> 0) & 0x3ffffff;
-		h1 += (le32_to_cpuvp(src +  3) >> 2) & 0x3ffffff;
-		h2 += (le32_to_cpuvp(src +  6) >> 4) & 0x3ffffff;
-		h3 += (le32_to_cpuvp(src +  9) >> 6) & 0x3ffffff;
-		h4 += (le32_to_cpuvp(src + 12) >> 8) | hibit;
+		h0 += (get_unaligned_le32(src +  0) >> 0) & 0x3ffffff;
+		h1 += (get_unaligned_le32(src +  3) >> 2) & 0x3ffffff;
+		h2 += (get_unaligned_le32(src +  6) >> 4) & 0x3ffffff;
+		h3 += (get_unaligned_le32(src +  9) >> 6) & 0x3ffffff;
+		h4 += (get_unaligned_le32(src + 12) >> 8) | hibit;
 
 		/* h *= r */
 		d0 = mlt(h0, r0) + mlt(h1, s4) + mlt(h2, s3) +
-- 
2.10.2

  parent reply	other threads:[~2016-11-07 19:47 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-02 17:58 [PATCH] poly1305: generic C can be faster on chips with slow unaligned access Jason A. Donenfeld
2016-11-02 20:09 ` Herbert Xu
2016-11-02 20:47   ` Sandy Harris
2016-11-02 21:06   ` Jason A. Donenfeld
2016-11-02 21:08     ` Herbert Xu
2016-11-02 21:25       ` Jason A. Donenfeld
2016-11-02 21:26         ` Herbert Xu
2016-11-02 22:00           ` Jason A. Donenfeld
2016-11-03  0:49             ` Herbert Xu
2016-11-03  7:24               ` Jason A. Donenfeld
2016-11-03 17:08                 ` David Miller
2016-11-03 22:20                   ` Jason A. Donenfeld
2016-11-03 22:20                     ` Jason A. Donenfeld
2016-11-03 22:20                     ` [WireGuard] " Jason A. Donenfeld
2016-11-04 17:37                     ` Eric Biggers
2016-11-04 17:37                       ` [WireGuard] " Eric Biggers
2016-11-07 18:08                       ` Jason A. Donenfeld
2016-11-07 18:08                         ` Jason A. Donenfeld
2016-11-07 18:08                         ` [WireGuard] " Jason A. Donenfeld
2016-11-07 18:23                         ` Jason A. Donenfeld
2016-11-07 18:23                           ` Jason A. Donenfeld
2016-11-07 18:23                           ` [WireGuard] " Jason A. Donenfeld
2016-11-07 18:26                         ` Eric Biggers
2016-11-07 18:26                           ` Eric Biggers
2016-11-07 18:26                           ` [WireGuard] " Eric Biggers
2016-11-07 19:02                           ` Jason A. Donenfeld
2016-11-07 19:02                             ` Jason A. Donenfeld
2016-11-07 19:02                             ` [WireGuard] " Jason A. Donenfeld
2016-11-07 19:25                             ` Eric Biggers
2016-11-07 19:25                               ` Eric Biggers
2016-11-07 19:25                               ` [WireGuard] " Eric Biggers
2016-11-07 19:41                               ` Jason A. Donenfeld
2016-11-07 19:41                                 ` Jason A. Donenfeld
2016-11-07 19:41                                 ` [WireGuard] " Jason A. Donenfeld
2016-11-07 19:12 ` [PATCH v2] " Jason A. Donenfeld
2016-11-07 19:43   ` [PATCH v3] " Jason A. Donenfeld
2016-11-12 23:27     ` kbuild test robot
2016-11-07 19:47   ` Jason A. Donenfeld [this message]
2016-11-07 20:40     ` [PATCH v4] " Eric Biggers
2016-11-08  7:52     ` Martin Willi
2016-11-08 17:26       ` Eric Biggers
2016-11-13 11:29     ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161107194709.20457-1-Jason@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=davem@davemloft.net \
    --cc=ebiggers@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin@strongswan.org \
    --cc=opensource@vdorst.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.