> -----Original Message----- > From: Barry Song <21cnbao@xxxxxxxxx> > Sent: Sunday, September 15, 2024 11:16 PM > To: Andre Glover <andre.glover@xxxxxxxxxxxxxxx> > Cc: tom.zanussi@xxxxxxxxxxxxxxx; minchan@xxxxxxxxxx; > senozhatsky@xxxxxxxxxxxx; hannes@xxxxxxxxxxx; yosryahmed@xxxxxxxxxx; > nphamcs@xxxxxxxxx; chengming.zhou@xxxxxxxxx; > herbert@xxxxxxxxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; Yu, Fenghua > <fenghua.yu@xxxxxxxxx>; Jiang, Dave <dave.jiang@xxxxxxxxx>; Feghali, Wajdi K > <wajdi.k.feghali@xxxxxxxxx>; Guilford, James <james.guilford@xxxxxxxxx>; Gopal, > Vinodh <vinodh.gopal@xxxxxxxxx>; Seshasayee, Bala > <bala.seshasayee@xxxxxxxxx>; Caldwell, Heath <heath.caldwell@xxxxxxxxx>; > Sridhar, Kanchana P <kanchana.p.sridhar@xxxxxxxxx>; linux- > kernel@xxxxxxxxxxxxxxx; linux-mm@xxxxxxxxx; ryan.roberts@xxxxxxx; linux- > crypto@xxxxxxxxxxxxxxx; dmaengine@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx> > 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
