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-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
