linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jeffrey Lien <Jeff.Lien@wdc.com>,
	Christoph Hellwig <hch@infradead.org>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-crypto\@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-block\@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-scsi\@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"herbert\@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
	"tim.c.chen\@linux.intel.com" <tim.c.chen@linux.intel.com>,
	David Darrington <david.darrington@wdc.com>,
	Jeff Furlong <jeff.furlong@wdc.com>
Subject: Re: [PATCH] Performance Improvement in CRC16 Calculations.
Date: Fri, 24 Aug 2018 12:29:25 -0400	[thread overview]
Message-ID: <yq1a7pb9196.fsf@oracle.com> (raw)
In-Reply-To: <CAKv+Gu-RwCrdgW69NVpyRLwGPGPCZx+ksTBM7NZk7v0-dzczGg@mail.gmail.com> (Ard Biesheuvel's message of "Fri, 24 Aug 2018 16:39:47 +0100")


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.

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

  reply	other threads:[~2018-08-24 16:29 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-10 19:12 [PATCH] Performance Improvement in CRC16 Calculations Jeff Lien
2018-08-10 19:23 ` Joe Perches
2018-08-10 20:02   ` Nicolas Pitre
2018-08-11  0:11     ` Joe Perches
2018-08-11  0:34       ` Nicolas Pitre
2018-08-11  2:39       ` Douglas Gilbert
2018-08-11  9:04         ` Joe Perches
2018-08-11 15:06           ` Joe Perches
2018-08-13 18:41             ` Jeffrey Lien
2018-08-13  3:36       ` Douglas Gilbert
2018-08-13  4:29         ` Joe Perches
2018-08-10 20:00 ` Nicolas Pitre
2018-08-10 20:16 ` Eric Biggers
2018-08-16 14:02   ` Jeffrey Lien
2018-08-16 14:22     ` Douglas Gilbert
2018-08-16 15:41       ` Christophe LEROY
2018-08-16 17:38         ` Douglas Gilbert
2018-08-17  3:20           ` Martin K. Petersen
2018-08-16 15:47     ` Christophe LEROY
2018-08-10 20:56 ` Douglas Gilbert
2018-08-11 15:36 ` Martin K. Petersen
2018-08-11 16:35   ` Joe Perches
2018-08-22  1:40   ` Martin K. Petersen
2018-08-22  6:20     ` Christoph Hellwig
2018-08-24 15:32       ` Jeffrey Lien
2018-08-24 15:39         ` Ard Biesheuvel
2018-08-24 16:29           ` Martin K. Petersen [this message]
2018-08-24 17:38             ` Ard Biesheuvel
2018-08-24 21:46               ` Martin K. Petersen
2018-08-24 21:54                 ` Ard Biesheuvel
2018-08-24 22:12                   ` Martin K. Petersen
2018-08-25  6:12                 ` Herbert Xu
2018-08-26  2:35                   ` Martin K. Petersen
2018-08-26  2:40                   ` [PATCH 1/4] crypto: Introduce notifier for new crypto algorithms Martin K. Petersen
2018-08-26  2:40                     ` [PATCH 2/4] crc-t10dif: Pick better transform if one becomes available Martin K. Petersen
2018-08-27  6:13                       ` Herbert Xu
2018-08-26  2:40                     ` [PATCH 3/4] crc-t10dif: Allow current transform to be inspected in sysfs Martin K. Petersen
2018-08-26  2:40                     ` [PATCH 4/4] block: Integrity profile init function to trigger module loads Martin K. Petersen
2018-08-26  8:22                       ` Ard Biesheuvel
2018-08-26 13:30                         ` Martin K. Petersen
2018-08-26 13:44                           ` Ard Biesheuvel
2018-08-26 13:48                             ` Martin K. Petersen
2018-08-27  6:09                     ` [PATCH 1/4] crypto: Introduce notifier for new crypto algorithms Herbert Xu
2018-08-30 14:57                       ` Martin K. Petersen
2018-08-30 15:00                       ` [PATCH v2 1/3] " Martin K. Petersen
2018-08-30 15:00                         ` [PATCH v2 2/3] crc-t10dif: Pick better transform if one becomes available Martin K. Petersen
2018-08-30 15:00                         ` [PATCH v2 3/3] crc-t10dif: Allow current transform to be inspected in sysfs Martin K. Petersen
2018-08-31 17:17                         ` [PATCH v2 1/3] crypto: Introduce notifier for new crypto algorithms Jeffrey Lien
2018-09-04  5:21                         ` Herbert Xu
2018-09-04 13:30                         ` Torsten Duwe
2018-08-24 16:30         ` [PATCH] Performance Improvement in CRC16 Calculations Martin K. Petersen
2018-08-13  4:44 ` Chaitanya Kulkarni
2018-08-13 11:45 ` David Laight
2018-08-13 13:50   ` David Laight
2018-08-13 22:44 ` Tim Chen
2018-08-15 12:51   ` Jeffrey Lien
2018-08-15 18:31 ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yq1a7pb9196.fsf@oracle.com \
    --to=martin.petersen@oracle.com \
    --cc=Jeff.Lien@wdc.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=david.darrington@wdc.com \
    --cc=hch@infradead.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=jeff.furlong@wdc.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=tim.c.chen@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).