Hey Jason, On Tue, 19 Nov 2019 at 16:18, Jason A. Donenfeld <Jason@xxxxxxxxx> 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@xxxxxxxxx> > 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.
