Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191213032849.GC1109@sol.localdomain> <20191214085608.b53yiogf432zxyw7@gondor.apana.org.au>
In-Reply-To: <20191214085608.b53yiogf432zxyw7@gondor.apana.org.au>
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
Date:   Sat, 14 Dec 2019 13:21:23 +0100
Message-ID: <CAHmME9rrwXJ7H6PENEzSzHUQusa3QpnNvSMV9-=++j8UDMVbsQ@mail.gmail.com>
Subject: Re: [PATCH crypto-next v2 1/3] crypto: poly1305 - add new 32 and
 64-bit generic versions
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

Hi Herbert,

On Sat, Dec 14, 2019 at 9:56 AM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > Now, it's possible that the performance gain outweighs this, and I too would
> > like to have the C implementation of Poly1305 be faster.  So if you'd like to
> > argue for the performance gain, fine, and if there's a significant performance
> > gain I don't have an objection.  But I'm not sure why you're at the same time
> > trying to argue that *adding* an extra implementation somehow makes the code
> > easier to audit and doesn't add complexity...
>
> Right.  We need the numbers not because we're somehow attached
> to the existing code, but we need them to show that we should
> carry the burden of having two C implementations, 32-bit vs 64-bit.

This info is now in the commit message of the version in my tree,
rather than sprinkled around casually in these threads. I also did a
bit more benchmarking this morning.

From <https://git.zx2c4.com/linux-dev/commit/?h=jd/crypto-5.5&id=900b79e1ff48f1f294ef3e9fb2520699c8895860>:
> Testing with kbench9000, depending on the CPU, the update function for
> the 32x32 version has been improved by 4%-7%, and for the 64x64 by
> 19%-30%. The 32x32 gains are small, but I think there's great value in
> having a parallel implementation to the 64x64 one so that the two can be
> compared side-by-side as nice stand-alone units.

I'll resubmit this on Monday.

Regards,
Jason