From: Herbert Xu <herbert@gondor.apana.org.au>
To: chris.mason@oracle.com (Chris Mason)
Subject: Re: [PATCH] Using Intel CRC32 instruction to accelerate	CRC32c	algorithm by new crypto API.
Cc: herbert@gondor.apana.org.au, dwmw2@infradead.org,
       austin_zhang@linux.intel.com, davem@davemloft.net,
       linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org
Organization: Core
In-Reply-To: <1217866496.29139.75.camel@think.oraclecorp.com>
User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.6.17-rc4 (i686))
Message-Id: <E1KQ3Be-0003T3-00@gondolin.me.apana.org.au>
Date: Tue, 05 Aug 2008 00:45:34 +0800
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1475
Lines: 34

Chris Mason <chris.mason@oracle.com> wrote:
> 
> Great to hear, that solves my main concern then.  There is still the
> embedded argument against needing all of crypto api just for libcrc32c.

The existing users are iSCSI, SCTP, Infiniband, all of which are
clearly crucial in the embedded space :)

> It does make sense to me to have a libcrc32c that does the HW detection
> and uses HW assist when present, and just have the cypto api call that.

Well then you're going to have to do the check on every call.

Seriously, I'm happy to trim off any fat from the crypto API for the
embedded space.  For a start, if you only needed hashing then we
could do without the legacy cipher/compress support.  That shaves
off 800 bytes on i386.  There is also still some legacy code in
api.c itself.  Getting rid of them should get us to around 2K.

On the other hand, one of the advantages of doing it through the
crypto API is that this kind of selection is useful for quite a
few operations, e.g., xor or even memcpy.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/