Re: [PATCH] drivers/crypto/nx: Add CRC and validation support for nx842

From: Dan Streetman
Date: Tue Sep 22 2015 - 11:09:16 EST


On Tue, Sep 22, 2015 at 10:42 AM, Herbert Xu
<herbert@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Sep 22, 2015 at 10:39:53AM -0400, Dan Streetman wrote:
>>
>> hmm, that's true, and that would simplify the code a lot! No need for
>> the header anymore. But, since the sw driver is sooo much slower, it
>> would be important to be able to communicate the alignment and size
>> limits to the caller of the crypto compression api, via cra_alignmask
>> and cra_blocksize (for minimum size), as well as new fields for max
>> size (maybe cra_maxsize) and buffer length multiple - i.e. the buffer
>> length must be a multiple of N (maybe cra_blockmult or cra_blockmodulo
>> or something). Otherwise callers would get unexpectedly slow
>> performance if they use the wrong alignment or size.
>
> Right. So who actually uses this?

currently, zswap. Probably nobody else. And zswap will always
provide an input buffer that is exactly one page, and output buffer
that is exactly 2 pages. So, it will always meet the 842 hw
requirements.

Maybe I got a little too excited about adding flexibility to the 842
hw driver? ;-)

As long as zswap is the only user of the 842 hw driver, it could be
changed to simply return error for any mis-aligned or mis-sized
buffer. A quick git grep of crypto_comp shows the only users of it
outside of crypto itself are ubifs and ipcomp. ubifs uses only lzo
and deflate. ipcomp appears to use only deflate (it also lists lzs and
lzjh but i don't see those implemented anywhere).

you think we should just strip out the 842-nx alignment/sizing code
and change it to fallback to the sw driver?


>
> Cheers,
> --
> Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/