Re: [PATCH 2/2] siw: Add support for CRC32C offload instructionusing libcrypto crc32c-intel

[Nicholas A. Bellinger]

On Wed, 2010-09-22 at 14:59 -0600, Jason Gunthorpe wrote:
> On Wed, Sep 22, 2010 at 01:38:21PM -0700, Nicholas A. Bellinger wrote:
> 
> > Indeed, this would clean up the explict RX/TX CRC32C case quite a
> > bit..  Unfortuately I am too busy with other items atm to cook up
> > this patch, but I would be happy to test it if someone wants to take
> > it.  ;)
> 
> Do you even need to do anything at all? crc32c is provided by
> crc32c-intel at a higher priority already, so it should be used if it
> is available..

I believe with the current libcrypto code that consumers are still
required to explictly ask for crc32c-intel offload.

>  
> > > Need CPUID module auto probing. I have an older patch that needs
> > > some fixes.
> 
> > Hmm, I don't see how that fits in here exactly.  Would you mind
> > elaborating a bit..?
> 
> Unless the module is loaded the optimized algorithm will not be
> available for automatic use. Maybe your patch causes it to autoload
> because of the by-name reference? Identifying modules to load by CPUID
> will let userspace auto load the appropriate ones based on CPU...
> 

Correct, this patch is so that autoload of crc32c-intel.ko 'just works'
and we do the fallback to the legacy slicing by 1x crc32c.ko when the
former is not availabe.

But I definately agree with Andi here that we should just add a wrapper
around the crypto_alloc_hash() usage of crc32c-intel and crc32c for
libcrypto consumers..

Thanks for your comments Jason!

--nab


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