From: David Woodhouse <dwmw2@infradead.org>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Austin Zhang <austin_zhang@linux.intel.com>,
davem@davemloft.net, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org
Subject: Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
Date: Mon, 04 Aug 2008 15:49:01 +0100 [thread overview]
Message-ID: <1217861341.3454.641.camel@pmac.infradead.org> (raw)
In-Reply-To: <20080804072015.0fcd23e7@infradead.org>
On Mon, 2008-08-04 at 07:20 -0700, Arjan van de Ven wrote:
> On Mon, 4 Aug 2008 22:04:35 +0800
> Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> > There only three crc32c users in the kernel tree and the crypto
> > interface will serve the perfectly.
>
> isn't it a bit heavy for something as simple as a crc?
> (which after all is one instruction now ;0)
It does seem that way. For users who care about 'bloat' and are _only_
interested in crc32, it's yet another chunk of extra infrastructure
which offers no benefit to them.
And even for people who don't care about that, it doesn't look
particularly good. It looks like btrfs would need either to keep setting
up a crypto context and then tearing it down, or have a pool of
long-standing contexts and do some kind of locking on them -- neither of
which seem particularly optimal compared with just calling into
libcrc32c.
We can't even set up one context per cpu and disable preempt while we
use it, can we? The routines are allowed to sleep?
(Although I have to admit I do like the fact that it'd only be available
through EXPORT_SYMBOL_GPL if we do force people to use the crypto
API...)
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
next prev parent reply other threads:[~2008-08-04 14:49 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-04 9:35 [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API Austin Zhang
2008-08-04 10:12 ` David Woodhouse
2008-08-04 10:25 ` Sebastian Siewior
2008-08-04 10:27 ` David Woodhouse
2008-08-04 10:48 ` Herbert Xu
2008-08-04 10:35 ` Austin Zhang
2008-08-04 10:45 ` David Woodhouse
2008-08-04 10:58 ` Austin Zhang
2008-08-04 11:25 ` David Woodhouse
2008-08-04 13:45 ` Chris Mason
2008-08-04 15:42 ` Herbert Xu
2008-08-04 16:14 ` Chris Mason
2008-08-04 16:45 ` Herbert Xu
2008-08-04 17:06 ` Arjan van de Ven
2008-08-04 17:10 ` Herbert Xu
2008-08-04 17:13 ` Herbert Xu
2008-08-05 11:10 ` Helge Hafting
2008-08-05 14:04 ` Herbert Xu
2008-08-04 18:02 ` Benoit Boissinot
2008-08-05 2:08 ` Herbert Xu
2008-08-04 14:04 ` Herbert Xu
2008-08-04 14:20 ` Arjan van de Ven
2008-08-04 14:49 ` David Woodhouse [this message]
2008-08-04 14:54 ` Herbert Xu
2008-08-04 15:12 ` Herbert Xu
2008-08-04 14:13 ` David Woodhouse
2008-08-04 14:17 ` Herbert Xu
2008-08-05 9:51 ` Austin Zhang
2008-08-04 14:18 ` Herbert Xu
2008-08-04 14:19 ` Herbert Xu
2008-08-05 9:59 ` Austin Zhang
2008-08-05 10:44 ` Herbert Xu
2008-08-04 17:27 ` Randy Dunlap
2008-08-05 10:12 ` Austin Zhang
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=1217861341.3454.641.camel@pmac.infradead.org \
--to=dwmw2@infradead.org \
--cc=arjan@infradead.org \
--cc=austin_zhang@linux.intel.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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