All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers3@gmail.com>
To: Ondrej Mosnacek <omosnacek@gmail.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	linux-crypto@vger.kernel.org, Jeffrey Walton <noloader@gmail.com>,
	Milan Broz <gmazyland@gmail.com>,
	Eric Biggers <ebiggers@google.com>
Subject: Re: [PATCH v3] crypto: gf128mul - define gf128mul_x_* in gf128mul.h
Date: Fri, 31 Mar 2017 20:44:07 -0700	[thread overview]
Message-ID: <20170401034407.GA598@zzz> (raw)
In-Reply-To: <20170331092703.2520-1-omosnacek@gmail.com>

On Fri, Mar 31, 2017 at 11:27:03AM +0200, Ondrej Mosnacek wrote:
> The gf128mul_x_ble function is currently defined in gf128mul.c, because
> it depends on the gf128mul_table_be multiplication table.
> 
> However, since the function is very small and only uses two values from
> the table, it is better for it to be defined as inline function in
> gf128mul.h. That way, the function can be inlined by the compiler for
> better performance.
> 
> For consistency, the other gf128mul_x_* functions are also moved to the
> header file. In addition, the code is rewritten to be constant-time.
> 
> After this change, the speed of the generic 'xts(aes)' implementation
> increased from ~225 MiB/s to ~235 MiB/s (measured using 'cryptsetup
> benchmark -c aes-xts-plain64' on an Intel system with CRYPTO_AES_X86_64
> and CRYPTO_AES_NI_INTEL disabled).
> 
> Signed-off-by: Ondrej Mosnacek <omosnacek@gmail.com>
> Cc: Eric Biggers <ebiggers@google.com>

Reviewed-by: Eric Biggers <ebiggers@google.com>

Also, I realized that for gf128mul_x_lle() now that we aren't using the table we
don't need to shift '_tt' but rather can use the constant 0xe100000000000000:

        /* equivalent to (u64)gf128mul_table_le[(b << 7) & 0xff] << 48
         * (see crypto/gf128mul.c): */
        u64 _tt = gf128mul_mask_from_bit(b, 0) & 0xe100000000000000;

        r->b = cpu_to_be64((b >> 1) | (a << 63));
        r->a = cpu_to_be64((a >> 1) ^ _tt);

I think that would be better and you could send a v4 to do it that way if you
want.  It's not a huge deal though.

Thanks!

- Eric

  reply	other threads:[~2017-04-01  3:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-31  9:27 [PATCH v3] crypto: gf128mul - define gf128mul_x_* in gf128mul.h Ondrej Mosnacek
2017-04-01  3:44 ` Eric Biggers [this message]
2017-04-01 15:13   ` Ondrej Mosnáček

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=20170401034407.GA598@zzz \
    --to=ebiggers3@gmail.com \
    --cc=davem@davemloft.net \
    --cc=ebiggers@google.com \
    --cc=gmazyland@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=noloader@gmail.com \
    --cc=omosnacek@gmail.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.