From: Ard Biesheuvel Subject: Re: [PATCH] Performance Improvement in CRC16 Calculations. Date: Fri, 24 Aug 2018 18:38:36 +0100 Message-ID: References: <1533928331-21303-1-git-send-email-jeff.lien@wdc.com> <20180822062016.GA10356@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Jeffrey Lien , Christoph Hellwig , "linux-kernel@vger.kernel.org" , "linux-crypto@vger.kernel.org" , "linux-block@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "herbert@gondor.apana.org.au" , "tim.c.chen@linux.intel.com" , David Darrington , Jeff Furlong To: "Martin K. Petersen" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org On 24 August 2018 at 17:29, Martin K. Petersen wrote: > > Ard, > >> Would it be possible to allocate the crypto transform upon first use >> instead of from an initcall? If crc_t10dif() is mostly called from >> non-process context, that would not really work, but otherwise, we >> could simply defer it (and occasional calls from non-process context >> that do occur would use the generic code until the point where another >> call from process context allocates the transform) > > The function is always called from user context. However, postponing the > crypto transform registration doesn't solve the common scenario of the > user booting off of a Fibre Channel/SAS/NVMe device with the desired > crct10dif-pclmul.ko module located on the boot drive. > > If there is no good way to teach crypto to update existing registrations > when a higher priority transformation becomes available, then we > probably need to explore tweaking dracut to unconditionally load > crct10dif-pclmul (and your ARM equivalent). Looks like there are already > hacks in place in dracut to preload crc32c for btrfs and XFS. > I'd prefer to handle this without help from userland. It shouldn't be too difficult to register a module notifier that only sets a flag (or the static key, even?), and to free and re-allocate the crc_t10dif transform if the flag is set. > Anyway. Just seems like the kernel is violating the principle of least > surprise here. The kernel should always pick the best available tool for > the job... > > -- > Martin K. Petersen Oracle Linux Engineering