From: <bala.seshasayee@linux.intel.com>
To: "'Barry Song'" <21cnbao@gmail.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>,
"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
Date: Fri, 27 Sep 2024 09:03:27 -0700 [thread overview]
Message-ID: <000001db10f6$cb3ca4b0$61b5ee10$@linux.intel.com> (raw)
In-Reply-To: <CAGsJ_4xREUbRWRZEO8EiEBdP9YN0Wip4_p58Cca=B4ZdPb7Mpg@mail.gmail.com>
> -----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
next prev parent reply other threads:[~2024-09-27 16:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-01 21:46 [RFC PATCH 0/3] by_n compression and decompression with Intel IAA Andre Glover
2024-05-01 21:46 ` [RFC PATCH 1/3] crypto: Add pre_alloc and post_free callbacks for acomp algorithms Andre Glover
2024-05-01 21:46 ` [RFC PATCH 2/3] crypto: add by_n attribute to acomp_req Andre Glover
2024-09-16 6:16 ` Barry Song
2024-09-27 16:03 ` bala.seshasayee [this message]
2024-05-01 21:46 ` [RFC PATCH 3/3] crypto: Add deflate-canned-byN algorithm to IAA Andre Glover
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000001db10f6$cb3ca4b0$61b5ee10$@linux.intel.com' \
--to=bala.seshasayee@linux.intel.com \
--cc=21cnbao@gmail.com \
--cc=Kanchana.P.Sridhar@intel.com \
--cc=chengming.zhou@linux.dev \
--cc=dave.jiang@intel.com \
--cc=davem@davemloft.net \
--cc=dmaengine@vger.kernel.org \
--cc=fenghua.yu@intel.com \
--cc=hannes@cmpxchg.org \
--cc=heath.caldwell@intel.com \
--cc=herbert@gondor.apana.org.au \
--cc=james.guilford@intel.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=nphamcs@gmail.com \
--cc=ryan.roberts@arm.com \
--cc=senozhatsky@chromium.org \
--cc=tom.zanussi@linux.intel.com \
--cc=vinodh.gopal@intel.com \
--cc=wajdi.k.feghali@intel.com \
--cc=yosryahmed@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox