On 10/16/2015 11:13 PM, Herbert Xu wrote: > On Fri, Oct 16, 2015 at 11:11:00PM +0800, Weigang Li wrote: >> This patch set introduces Asynchronous Compression API. >> What is proposed is a new crypto type called crypto_acomp_type, >> plus new struct acomp_alg and struct crypto_acomp, together with number >> of helper functions to register acomp type algorithms and allocate tfm >> instances. This is to make it similar to how the existing crypto API >> works for the ablkcipher, and akcipher types. >> The operations the new interface will provide are: >> >> int (*compress)(struct acompress_request *req); >> int (*decompress)(struct acompress_request *req); >> >> The benefits it gives interface are: >> - the new interface allows for asynchronous implementations and >> scatterlist buffer that can use hardware to offload the compression >> operations, the new asynchronous API can be called by the linux kernel >> components (i.e., btrfs) who want to use hardware acceleration for data >> compression. >> >> New helper functions have been added to allocate crypto_acomp instances >> and invoke the operations to make it easier to use. >> >> Signed-off-by: Weigang Li <weigang...@intel.com> > > Thanks for the patch! Joonsoo Kim is also working on the compression > interface for zram. Could you two collaborate and come up with one > interface rather than two? > > Cheers, > Hello Herbert,
After sync-up with Joonsoo Kim, we think it may be not feasible for a s/w implementation of the sg-list based asynchronous interface, we propose separate interfaces (patches) for acomp & ccomp. The reasons are: 1. to support sg-list in the ccomp (like what shash/ahash did), the partial update is required, some algorithms do not support partial update (i.e., lzo), that means: 2. the format of output buffer (sg-list) will be different, e.g., the lzo need contain the "length" info for each block in the output sg-list in order to de-compression, while zlib doesn't need, then it is difficult to have a single async sg-list i/f. 3. to compress a sg-list buffer, the lzo also requires an intermediate buffer to save the output of a block, and copy it back to the sg-list output buffer, it will introduce the complexity and cost, we don't see value for sg-list support in a s/w compression. Any suggestions? -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
