Add the 'by_n' attribute to the acomp_req. The 'by_n' attribute can be
used a directive by acomp crypto algorithms for splitting compress and
decompress operations into "n" separate jobs.
 
Signed-off-by: Andre Glover <andre.glover@linux.intel.com>
---
 include/crypto/acompress.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/crypto/acompress.h b/include/crypto/acompress.h
index 2b73cef2f430..c687729e1966 100644
--- a/include/crypto/acompress.h
+++ b/include/crypto/acompress.h
@@ -25,6 +25,7 @@
  * @slen:	Size of the input buffer
  * @dlen:	Size of the output buffer and number of bytes produced
  * @flags:	Internal flags
+ * @by_n:	by_n setting used by acomp alg
  * @__ctx:	Start of private context data
  */
 struct acomp_req {
@@ -34,6 +35,7 @@ struct acomp_req {
 	unsigned int slen;
 	unsigned int dlen;
 	u32 flags;
+	u32 by_n;
 	void *__ctx[] CRYPTO_MINALIGN_ATTR;
 };
 
-- 
2.27.0

On Thu, May 2, 2024 at 5:46 AM Andre Glover
<andre.glover@linux.intel.com> wrote:
>
> Add the 'by_n' attribute to the acomp_req. The 'by_n' attribute can be
> used a directive by acomp crypto algorithms for splitting compress and
> decompress operations into "n" separate jobs.

Hi Andre,

I am definitely in favor of the patchset idea. However, I'm not convinced that a
separate by_n API is necessary. Couldn’t this functionality be handled
automatically within your driver? For instance, if a large folio is detected,
could it automatically apply the by_n concept?

Am I overlooking something that makes exposing the API necessary in
this case?

>
> Signed-off-by: Andre Glover <andre.glover@linux.intel.com>
> ---
>  include/crypto/acompress.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/include/crypto/acompress.h b/include/crypto/acompress.h
> index 2b73cef2f430..c687729e1966 100644
> --- a/include/crypto/acompress.h
> +++ b/include/crypto/acompress.h
> @@ -25,6 +25,7 @@
>   * @slen:      Size of the input buffer
>   * @dlen:      Size of the output buffer and number of bytes produced
>   * @flags:     Internal flags
> + * @by_n:      by_n setting used by acomp alg
>   * @__ctx:     Start of private context data
>   */
>  struct acomp_req {
> @@ -34,6 +35,7 @@ struct acomp_req {
>         unsigned int slen;
>         unsigned int dlen;
>         u32 flags;
> +       u32 by_n;
>         void *__ctx[] CRYPTO_MINALIGN_ATTR;
>  };
>
> --
> 2.27.0
>

Thanks
Barry

> -----Original Message-----
> From: Barry Song <21cnbao@gmail.com>
> Sent: Sunday, September 15, 2024 11:16 PM
> To: Andre Glover <andre.glover@linux.intel.com>
> Cc: tom.zanussi@linux.intel.com; minchan@kernel.org;
> senozhatsky@chromium.org; hannes@cmpxchg.org; yosryahmed@google.com;
> nphamcs@gmail.com; chengming.zhou@linux.dev;
> herbert@gondor.apana.org.au; davem@davemloft.net; Yu, Fenghua
> <fenghua.yu@intel.com>; Jiang, Dave <dave.jiang@intel.com>; Feghali, Wajdi K
> <wajdi.k.feghali@intel.com>; Guilford, James <james.guilford@intel.com>; Gopal,
> Vinodh <vinodh.gopal@intel.com>; Seshasayee, Bala
> <bala.seshasayee@intel.com>; Caldwell, Heath <heath.caldwell@intel.com>;
> Sridhar, Kanchana P <kanchana.p.sridhar@intel.com>; linux-
> kernel@vger.kernel.org; linux-mm@kvack.org; ryan.roberts@arm.com; linux-
> crypto@vger.kernel.org; dmaengine@vger.kernel.org
> Subject: Re: [RFC PATCH 2/3] crypto: add by_n attribute to acomp_req
> 
> On Thu, May 2, 2024 at 5:46 AM Andre Glover <andre.glover@linux.intel.com>
> wrote:
> >
> > Add the 'by_n' attribute to the acomp_req. The 'by_n' attribute can be
> > used a directive by acomp crypto algorithms for splitting compress and
> > decompress operations into "n" separate jobs.
> 
> Hi Andre,
> 
> I am definitely in favor of the patchset idea. However, I'm not convinced that a
> separate by_n API is necessary. Couldn’t this functionality be handled
> automatically within your driver? For instance, if a large folio is detected, could it
> automatically apply the by_n concept?
> 
> Am I overlooking something that makes exposing the API necessary in this case?

Hi Barry,

The 'deflate-iaa-canned' compression algorithm is fully compatible with the deflate standard. Andre's patchset introduces 'canned-by_n' as a new compression algorithm, which is not a deflate stream since it has a different header (for the by_n chunks).
The same 'canned-by_n' algorithm along with the value of the acomp_req ‘by_n’ attribute would be used to compress and decompress a given input buffer.
Furthermore, with a tunable 'by_n' , the user can experiment with different values of by_n for different mTHP sizes to understand trade-offs in performance vs. compression ratio.

Thanks
Bala