Since we use custom backend implementation, we remove the ability
for users to use algorithms from crypto backend. This breaks
backward compatibility, user doesn't necessarily use one of the
algorithms from "custom" backends defined in zram folder.
For example, he can use some driver with hardware compression support.

This patchset adds an option that allows user to enable Crypto API
backend support. Crypto API backend is also implemented in a separate
file backend_crypto_api like the other custom backends.

Alexey Romanov (3):
  zram: pass zcomp instead of zcomp_params to create_context method
  zram: store crypto backends in list instead of array
  zram: introduce crypto-api backend

 drivers/block/zram/Kconfig              |  10 ++
 drivers/block/zram/Makefile             |   1 +
 drivers/block/zram/backend_842.c        |  14 +-
 drivers/block/zram/backend_842.h        |   2 +-
 drivers/block/zram/backend_crypto_api.c | 117 +++++++++++++++
 drivers/block/zram/backend_crypto_api.h |  10 ++
 drivers/block/zram/backend_deflate.c    |  15 +-
 drivers/block/zram/backend_deflate.h    |   2 +-
 drivers/block/zram/backend_lz4.c        |  15 +-
 drivers/block/zram/backend_lz4.h        |   2 +-
 drivers/block/zram/backend_lz4hc.c      |  15 +-
 drivers/block/zram/backend_lz4hc.h      |   2 +-
 drivers/block/zram/backend_lzo.c        |  14 +-
 drivers/block/zram/backend_lzo.h        |   2 +-
 drivers/block/zram/backend_lzorle.c     |  14 +-
 drivers/block/zram/backend_lzorle.h     |   2 +-
 drivers/block/zram/backend_zstd.c       |  15 +-
 drivers/block/zram/backend_zstd.h       |   2 +-
 drivers/block/zram/zcomp.c              | 183 ++++++++++++++++++------
 drivers/block/zram/zcomp.h              |  11 +-
 drivers/block/zram/zram_drv.c           |   7 +
 21 files changed, 390 insertions(+), 65 deletions(-)
 create mode 100644 drivers/block/zram/backend_crypto_api.c
 create mode 100644 drivers/block/zram/backend_crypto_api.h

-- 
2.34.1

On (24/11/19 15:27), Alexey Romanov wrote:
> Since we use custom backend implementation, we remove the ability
> for users to use algorithms from crypto backend. This breaks
> backward compatibility, user doesn't necessarily use one of the
> algorithms from "custom" backends defined in zram folder.

Sorry, no, we are not adding this for a hypothetical scenario.

> For example, he can use some driver with hardware compression support.

Such as?  Pretty much all H/W compression modules (I'm aware of)
that people use with zram are out-of-tree.

Hi Sergey,

On Wed, Nov 20, 2024 at 12:15:29PM +0900, Sergey Senozhatsky wrote:
> On (24/11/19 15:27), Alexey Romanov wrote:
> > Since we use custom backend implementation, we remove the ability
> > for users to use algorithms from crypto backend. This breaks
> > backward compatibility, user doesn't necessarily use one of the
> > algorithms from "custom" backends defined in zram folder.
> 
> Sorry, no, we are not adding this for a hypothetical scenario.
> 
> > For example, he can use some driver with hardware compression support.
> 
> Such as?  Pretty much all H/W compression modules (I'm aware of)
> that people use with zram are out-of-tree.

At least we have this:

drivers/crypto/nx/nx-common-powernv.c:1043:    .cra_flags        = CRYPTO_ALG_TYPE_COMPRESS,
drivers/crypto/nx/nx-common-pseries.c:1020:    .cra_flags        = CRYPTO_ALG_TYPE_COMPRESS,
drivers/crypto/cavium/zip/zip_main.c:377:    .cra_flags        = CRYPTO_ALG_TYPE_COMPRESS,
drivers/crypto/cavium/zip/zip_main.c:392:    .cra_flags        = CRYPTO_ALG_TYPE_COMPRESS,

Anyway, if we want to completely abandon Crypto API, these modules
still need to be supported in zram.

-- 
Thank you,
Alexey

On (24/11/21 12:11), Alexey Romanov wrote:
> > Sorry, no, we are not adding this for a hypothetical scenario.
> > 
> > > For example, he can use some driver with hardware compression support.
> > 
> > Such as?  Pretty much all H/W compression modules (I'm aware of)
> > that people use with zram are out-of-tree.
> 
> At least we have this:
> 
> drivers/crypto/nx/nx-common-powernv.c:1043:    .cra_flags        = CRYPTO_ALG_TYPE_COMPRESS,
> drivers/crypto/nx/nx-common-pseries.c:1020:    .cra_flags        = CRYPTO_ALG_TYPE_COMPRESS,
> drivers/crypto/cavium/zip/zip_main.c:377:    .cra_flags        = CRYPTO_ALG_TYPE_COMPRESS,
> drivers/crypto/cavium/zip/zip_main.c:392:    .cra_flags        = CRYPTO_ALG_TYPE_COMPRESS,
> 
> Anyway, if we want to completely abandon Crypto API

It's more complicated than that.

> these modules still need to be supported in zram.

We support what we have always claimed we supported, namely
what is listed in drivers/block/zram/Kconfig.  That's how one
enables a particular algorithm in zram - during zram configuration.
If those algos are not in zram's Kconfig after so many years,
then it's most likely because people don't use them with zram.
If we ever need backends for those H/W algos, then I really would
prefer a patch from folks that have a corresponding hardware to
run and test it on.  The thing is, zram, in its current form and
shape, imposes strict requirements on comp implementation.

So we should not add algos just because they are there (especially
H/W algos) that's how we added 842, lz4hc many years ago and now
have to carry them around.  We are not doing that again.