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: <20191108122240.28479-1-ardb@kernel.org> <20191115060727.eng4657ym6obl4di@gondor.apana.org.au>
 <CAHmME9oOfhv6RN00m1c6c5qELC5dzFKS=mgDBQ-stVEWu00p_A@mail.gmail.com>
 <20191115090921.jn45akou3cw4flps@gondor.apana.org.au> <CAHmME9rxGp439vNYECm85bgibkVyrN7Qc+5v3r8QBmBXPZM=Dg@mail.gmail.com>
In-Reply-To: <CAHmME9rxGp439vNYECm85bgibkVyrN7Qc+5v3r8QBmBXPZM=Dg@mail.gmail.com>
From:   Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Tue, 19 Nov 2019 16:34:42 +0100
Message-ID: <CAKv+Gu96xbhS+yHbEjx6dD-rOcB8QYp-Gnnc3WMWfJ9KVbJzcg@mail.gmail.com>
Subject: Re: [PATCH v5 00/34] crypto: crypto API library interfaces for WireGuard
To:     "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc:     Herbert Xu <herbert@gondor.apana.org.au>,
        Ard Biesheuvel <ardb@kernel.org>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        David Miller <davem@davemloft.net>,
        Samuel Neves <sneves@dei.uc.pt>, Arnd Bergmann <arnd@arndb.de>,
        Eric Biggers <ebiggers@google.com>,
        Andy Lutomirski <luto@kernel.org>,
        Martin Willi <martin@strongswan.org>,
        Rene van Dorst <opensource@vdorst.com>,
        David Sterba <dsterba@suse.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

Hey Jason,

On Tue, 19 Nov 2019 at 16:18, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Hey Ard, Herbert, Dave,
>
> The series looks fine. Ard -- thanks so much for picking up the work
> and making this happen. As far as I'm concerned, this is "most" of
> Zinc, simply without calling it "Zinc", and minus a few other things
> that I think constitutes an okay compromise and good base for moving
> forward.
>
> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
>

Thanks!

> The TODO list for me remains the same, and now I can get moving with that:
>
> - Zinc's generic C implementation of poly1305, which is faster and has
> separate implementations for u64 and u128.
> - x86_64 ChaCha20 from Zinc. Will be fun to discuss with Martin and Andy.
> - x86_64 Poly1305 from Zinc.

As I pointed out in the private discussions we had, there are two
aspects two AndyP's benchmarking that don't carry over 100% to the
Linux kernel:
- Every microarchitecture is given equal weight, regardless of the
likelihood that the code will actually run on it. This makes some
sense for OpenSSL, I guess, but not for the kernel.
- Benchmarks are typically based on the performance of the core
cryptographics transformation rather than a representative workload.
This is especially relevant for network use cases, where packet sizes
are not necessarily fixed and usually not a multiple of the block size
(as opposed to disk encryption, where every single call is the same
size and a power of 2)

So for future changes, could we please include performance numbers
based on realistic workloads?

> - Resurrecting the big_keys patch and receiving DavidH's review on that.

My concern here (but we can discuss it in the context of a repost) is
that this will pull the accelerated chacha20 and poly1305 code (if
enabled)  into the core kernel, given that big_keys is not a tristate
option. So perhaps we can park this one until we know how to proceed
with static calls or alternative approaches?

> - WireGuard! Hurrah!
>

I'm a bit surprised that this only appears at the end of your list :-)

> If you have any feedback on how you'd like this prioritized, please
> pipe up. For example Dave - would you like WireGuard *now* or sometime
> later? I can probably get that cooking this week, though I do have
> some testing and fuzzing of it to do on top of the patches that just
> landed in cryptodev.
>

We're at -rc8, and wireguard itself will not go via the crypto tree so
you should wait until after the merge window, rebase it onto -rc1 and
repost it.