[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1KQ1jD-00039b-00@gondolin.me.apana.org.au>
Date: Mon, 04 Aug 2008 23:12:07 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: arjan@...radead.org (Arjan van de Ven)
Cc: herbert@...dor.apana.org.au, dwmw2@...radead.org,
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.
Arjan van de Ven <arjan@...radead.org> 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)
Well AES on the PadLock is also a single instruction and nobody
has ever complained :)
Seriously, the crypto code is extremely small on the data path.
The heaviest part is the indirect function call but you have to
have that in order to support multiple implementations cleanly.
All the fat is on the control path, i.e., tfm allocation. For
crc32c you only need a single tfm since all the state is stored
in the request object.
Note that you should ignore the existing crc32c user, iSCSI as
it was written before the new crypto hash interface was available.
I will be converting it along with the other two crc32c users. to
the new ahash interface.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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