[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1217861341.3454.641.camel@pmac.infradead.org>
Date: Mon, 04 Aug 2008 15:49:01 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Arjan van de Ven <arjan@...radead.org>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
Austin Zhang <austin_zhang@...ux.intel.com>,
davem@...emloft.net, linux-kernel@...r.kernel.org,
linux-crypto@...r.kernel.org
Subject: Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c
algorithm by new crypto API.
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@...dor.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@...el.com Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists