[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e3a3a1d3-cce6-4bee-b90b-f75faace14f8@linux.ibm.com>
Date: Mon, 19 May 2025 14:09:49 +0200
From: Zaslonko Mikhail <zaslonko@...ux.ibm.com>
To: Herbert Xu <herbert@...dor.apana.org.au>,
Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Minchan Kim <minchan@...nel.org>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Heiko Carstens <hca@...ux.ibm.com>,
Ilya Leoshkevich <iii@...ux.ibm.com>
Subject: Re: [PATCH 2/2] zram: support deflate-specific params
Hello,
On 15.05.2025 05:38, Herbert Xu wrote:
> On Thu, May 15, 2025 at 12:32:39PM +0900, Sergey Senozhatsky wrote:
>>
>> This is not exported yet.
>>
>> I lean toward not filtering/limiting anything and just permit
>> what include/linux/zlib.h promises [1]. Would that be OK for
>> Crypto API?
>
> I don't have a problem with that.
>
> It just makes the hardware implementor's job a little bit harder,
> because the Crypto API requires every implementation of a given
> algorithm to be equivalent. So if the software zlib supports
> a full level specification, then so must the s390 version of zlib.
> If it cannot support a parameter, then it must provide a software
> fallback.
That's exactly how s390 zlib hardware support works, including
fallback to software.
My intention was to use specific zlib compression parameters
(window size and compression level), as default values for zram
delflate on s390 to benefit from hardware acceleration.
>
> Cheers,
Thanks,
Mikhail
Powered by blists - more mailing lists