| Message ID | 20241119122713.3294173-1-avromanov@salutedevices.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | zram: introduce crypto-backend api | expand |
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.
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.