Hi Herbert, > Hi Andrew: > > Please drop this patch as it should've gone through the crypto > tree. Not Andrew, i wrote a note in cover-letter and said zswap was the direct user for this patch, so it is good to go through mm. but it's also fine to go through crypto. > > Also per previous discussion, it needs to demonstrate that this > actually makes a difference in the right direction vs. using the > scomp interface directly (as opposed to comparing against the > code-base without this patch as it does right now). i assume you mean we should compare the below three 1. directly use scomp 2. use acomp with scomp backend w/o this patch 3. use acomp with scomp backend w/ this patch I would expect 2 is worse, 1 and 3 are basically equal. But the problem of directly using scomp is that we are losing the chance to use hardware like intel/qat/qat_common/ and hisilicon/zip/zip_crypto.c to offload the overhead of compression/decompression as those drivers have no scomp. On the other hand, acomp with acomp backend can sometimes decrease cpu usage especially when PAGE_SIZE is big such as 64KiB while providing higher performance. only if scomp is still an open option for those drivers to support in crypto subsystem, it seems moving to directly scomp interface is not sensible. as it is closing a door of offloading compression/decompression unconditionally. but years ago, i heard zip driver - hisilicon had pushback while scomp was also implemented as scomp was not welcomed for a hardware driver? +Zhou Wang, please correct me if i am wrong on this :-) i think we can safely go ahead with the coming data to demonstrate 1 is equal 3 for hardware without acomp driver? > > Thanks, > -- > Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > Home Page: http://gondor.apana.org.au/~herbert/ Thanks Barry
