From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Gleixner Subject: Re: [PATCH net-next v3 05/17] zinc: ChaCha20 x86_64 implementation Date: Tue, 11 Sep 2018 11:09:17 +0200 (CEST) Message-ID: References: <20180911010838.8818-1-Jason@zx2c4.com> <20180911010838.8818-6-Jason@zx2c4.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: "Jason A. Donenfeld" , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, davem@davemloft.net, Greg Kroah-Hartman , Andy Lutomirski , Jean-Philippe Aumasson , Andy Polyakov , Ingo Molnar , the arch/x86 maintainers , Linux Crypto Mailing List To: Samuel Neves Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org On Tue, 11 Sep 2018, Samuel Neves wrote: > On Tue, Sep 11, 2018 at 9:22 AM, Thomas Gleixner wrote: > > On Mon, 10 Sep 2018, Jason A. Donenfeld wrote: > >> lib/zinc/Makefile | 4 + > >> lib/zinc/chacha20/chacha20-x86_64-glue.h | 102 + > >> lib/zinc/chacha20/chacha20-x86_64.S | 2632 ++++++++++++++++++++++ > > > > Just a stupid question. What's the rationale of putting that into lib/zinc > > instead of having it in arch/x86/crypto? > > > > This is covered on the 02/17 commit message, whose relevant paragraph follows: Well, being only cc'ed on only half of the patches does not really help. > > It also organizes the implementations in a simple, straight-forward, > > and direct manner, making it enjoyable and intuitive to work on. > > Rather than moving optimized assembly implementations into arch/, it > > keeps them all together in lib/zinc/, making it simple and obvious to > > compare and contrast what's happening. This is, notably, exactly what > > the lib/raid6/ tree does, and that seems to work out rather well. It's > > also the pattern of most successful crypto libraries. The architecture- > > specific glue-code is made a part of each translation unit, rather than > > being in a separate one, so that generic and architecture-optimized code > > are combined at compile-time, and incompatibility branches compiled out by > > the optimizer. Fair enough.