On Tue, Nov 19, 2019 at 4:34 PM Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > - Zinc's generic C implementation of poly1305, which is faster and has > > separate implementations for u64 and u128. I assume your AndyP comment below didn't apply to this top item here. This one should be fairly uncontroversial in your opinion, right? > > - 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? Yea I share your concerns here. From preliminary results, I think the Poly1305 code will be globally better, and I don't think we'll need an abundance of discussion about it. The ChaCha case is more interesting. I'll submit this with lots of packet-sized microbenchmarks, as well as on-the-wire WireGuard testing. Eric - I'm guessing you don't care too much about Adamantium performance on x86 where people are probably better off with AES-XTS, right? Are there other specific real world cases we care about? IPsec is another one, but those concerns, packet-size wise, are more or less the same as for WireGuard. But anyway, we can cross this bridge when we come to it. > > - WireGuard! Hurrah! > > > I'm a bit surprised that this only appears at the end of your list :-) Haha, "last but not least" :) > > > 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. Thanks, yea, that makes sense. Netdev also has its own merge window schedule that I should aim to meet. I guess, based on this if I'm understanding correctly, we're looking at WireGuard for 5.5? Jason
