Subject: Re: FW: [Fwd: [PATCH]Using Intel CRC32 instruction to implement
	hardware accelerated CRC32c algorithm.]
From: austin zhang <austin_zhang@linux.intel.com>
To: herbert@gondor.apana.org.au
Cc: davem@davemloft.net, chaapala@cisco.com, linux-crypto@vger.kernel.org,
       linux-kernel@vger.kernel.org, arjan@linux.intel.com
In-Reply-To: <000901c8e0d4$6f5cf230$7fb410ac@ccr.corp.intel.com>
References: <000901c8e0d4$6f5cf230$7fb410ac@ccr.corp.intel.com>
Content-Type: text/plain; charset=UTF-8
Date: Tue, 08 Jul 2008 06:25:54 -0400
Message-Id: <1215512754.2906.23.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1446
Lines: 33

Thanks, ﻿Herbert, see my reply as below.
> 1) Utilise the brand new crypto ahash interface (note that it's
﻿When you mentioned ahash, can you give a explanation on it? 
The brand new crypto interface is different with crypto/api?
> designed to support sync just as well as async despite the name)
﻿Do you mean use async_xxx interface?
> to rewrite the crypto/crc32c implementation such that one tfm can
> be used by multiple users.  All that has to be done is to move
> the state from the tfm into the request object.
 
> 2) Convert all crc32c users to use the crypto interface and phase
> out lib/crc32c completely.
> 
> 3) Add the Intel-specific crc32c implementation through the crypto
> API.
Agreed. And which module in crypto is the template for following the crypto API?

> That way none of this iffy testing will be necessary.  Even better,
> most users can share one common tfm and therefore there will only
> be one test for the CPU flag at boot time rather than every time
> it's used.
> 
> In fact, we could even skip 2) and reimplement lib/crc32c as a
> wrapper on the crypto crc32c interface with a shared tfm so you
> don't need to modify its existing users.
Good idea.
> Cheers,

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/