From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 25CA0CDD1C9 for ; Fri, 27 Sep 2024 16:03:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B2D946B008C; Fri, 27 Sep 2024 12:03:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ADE2E6B00C4; Fri, 27 Sep 2024 12:03:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 97DB46B00CB; Fri, 27 Sep 2024 12:03:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 751136B008C for ; Fri, 27 Sep 2024 12:03:37 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id EEFC8AC7E1 for ; Fri, 27 Sep 2024 16:03:36 +0000 (UTC) X-FDA: 82610988432.17.1F4C11F Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by imf27.hostedemail.com (Postfix) with ESMTP id 4C9414002D for ; Fri, 27 Sep 2024 16:03:33 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=QMSI0Vju; spf=none (imf27.hostedemail.com: domain of bala.seshasayee@linux.intel.com has no SPF policy when checking 198.175.65.9) smtp.mailfrom=bala.seshasayee@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727452851; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=eMlisuPU8aSOMFD/1F9ex1awVaAko4nscyew5rE08e0=; b=bnMWzipERygTAHvJgbrgC7aQ+xkqA+9p3dm1CI4zLd0R3WqGI4Mr6sEEtdzwhD2sAw1MFF Dnp/aHWYyCbEXDI7gYmoZ7Oz7fksQ6oHDRHZCxp8TIcLzTMXnjSjrSzH16bvMaoFGugea/ HmyaWhjv92pYVuPwEPR3wh0dowde9dA= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=QMSI0Vju; spf=none (imf27.hostedemail.com: domain of bala.seshasayee@linux.intel.com has no SPF policy when checking 198.175.65.9) smtp.mailfrom=bala.seshasayee@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727452851; a=rsa-sha256; cv=none; b=dpCBD5Pu7rDykJaXQuJrnd9LUlPi2WJO4wP5J5loVOUMti9EEuX5KPljeOBPecv1BGtjnH NYalRVOrnXrqZ7eQrJKTDHtSI/MBjuW/SRXjWJGuNEW+awLcaVNOAk0H8X2RMY5d4GSs0k UHwhpokcEl8jfYwPOQLZJLtiKSsuTMQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727453014; x=1758989014; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=eMlisuPU8aSOMFD/1F9ex1awVaAko4nscyew5rE08e0=; b=QMSI0Vjunwo6oMbQA8TFJp7elDcL6Pysq4Q89Q/yxIEubbda2MXcf6zu yIS7BcWzyC5xd4bJZ98y+dw3/lTDf189IzCzthmM5/QjuyJs7uAr3/nH/ mkHMWTYJRuj9DgG/7JPfVFArUySiLKOg0JXEY8vFobAy6su8yMp6hCsZP LUo/jopFEw4c0POW+MPRtovERzU30kh1uQk7bl21estVdFR/VrIlHU5b0 GKyK6BH/tlt364yhhyNHvGodeGYww7GsAC/k75eQUnSQcnXsVI3nE8Vc0 +wXTzqbJgM3jQU/6kiIXT1wR6OvYG0memRYSwnWaFWp9KdQpCtin2TGSA w==; X-CSE-ConnectionGUID: fayspeksSJqRfkm6iLi3rw== X-CSE-MsgGUID: NTkTgVk+Tp60gaIGy0SmMw== X-IronPort-AV: E=McAfee;i="6700,10204,11208"; a="49129851" X-IronPort-AV: E=Sophos;i="6.11,159,1725346800"; d="scan'208";a="49129851" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2024 09:03:32 -0700 X-CSE-ConnectionGUID: WYjpbBapSlSP2KIipdKD+A== X-CSE-MsgGUID: D9tt5ylpQWCX5Qd1hHyaOw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,159,1725346800"; d="scan'208";a="73004773" Received: from bseshasa-mobl.amr.corp.intel.com (HELO bseshasaMOBL) ([10.246.171.145]) by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2024 09:03:28 -0700 From: To: "'Barry Song'" <21cnbao@gmail.com> Cc: , , , , , , , , , "Yu, Fenghua" , "Jiang, Dave" , "Feghali, Wajdi K" , "Guilford, James" , "Gopal, Vinodh" , "Caldwell, Heath" , "Sridhar, Kanchana P" , , , , , References: <8fe04e86f0907588d210885ac91965960f97f450.1714581792.git.andre.glover@linux.intel.com> In-Reply-To: Subject: RE: [RFC PATCH 2/3] crypto: add by_n attribute to acomp_req Date: Fri, 27 Sep 2024 09:03:27 -0700 Message-ID: <000001db10f6$cb3ca4b0$61b5ee10$@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHanBEURTUo4d1RW0OV8cvHU+0CnrJax8IAgBHsYLA= Content-Language: en-us X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 4C9414002D X-Stat-Signature: aihus6tsefchx3addnhgu5oxo3kiq1bn X-Rspam-User: X-HE-Tag: 1727453013-989164 X-HE-Meta: U2FsdGVkX18WemP5WnxICSWO9+ei2njqDwYyhFrXuntWg7Li7Hj04IVi2ZOo/N4ksPNH4PoAgC/pc/nNcSLLjc4qpHx/W8UbaiUGLx91Mms7mpVWrPw+WzPYY/WpDExF+/ATZmFQA145YwKPRPkCav1NH0/yw08yFHjHP8TnfcnP2T/GHyqYPduJlfJgHnX5GWpzosrU8x2bfgDEJ4qkmonOhUxdIvVV6dCARYk4a62AJvwrklEMjWOz2Ni80EWHZ9jm5Z95W2vmSs6NDp0xLgPIK/uCM2u5cmyoQ4R6OmdJbDm8kLeHUEtMAcOFfxwC/NvhX/Co+UUYq5rrUL3y8lBYIAOYkcNIW7YyQEusSS2pTJLETKGY1fMdkXQSW1hT9j6y8HiWolS8Q4chQEcuatv8642n6ouRnGcGUTc7CmHSBQH9mE2BoV/LjNOh2F1cCEDY+NOuT3rjKKD8vyzhZYtdTE+F0si+xUJJAwGE/th/boYsn7022xPBPb7A3QrLEadqlEiCZOCwomMmbCwH2xVQs1C+OawZpChlrm1EeS4HTtaWY5hEcP1fqSqcMtiyh0cP3h7j8+FykvdYbV9aYWdO/C4dpJPlBOs5My8G8/5l+Kx0pszXYY8vHfXeU1iXZcJ4Q3gTHqYVhBw+4l5OrONglrSJmvTibGGFF6zUhJWwbednHdxAf7IzqqPkRaP0kXHfW3wdOegNzBGFVesIMDtlDrCJFmgdYsHFLH1rgdOYFDUH1rBN/oaVvKC+6KA4eezuWqiVMPGKGGuYZrtg5psByZda/b914e/qzYi/kynZGfT+rstCmVJalguJVovUfOpow/9OBZ1XJQ6HxtRSigk0A53PgFdTuPCTReA9wWGnZpHqeij1n5hQSef7r0GgArwXpejAs3mWBur1MoKBiPYzgPqZq8C2msp3GcUM5F7M1VeTzzyCAm9KmF8lFXtkNtTgWQ6oYwWykcbV5Aq JMlfcdw8 3FQ2KokpxWixF/ZyZITZDVEfyuGg9pr9NgemyCM1DoyAOg8na+zwmltUtX+hgEdKnCRkHyXKWUNpP04YAFtPrwErBCenqZJR9FgOYkDgU4mUN2v4CnCFHmQoH5FJ5swb/7BdtufQmeJJkYFXuUpwm0GKe0SMpSMOCXrZo8zOXtOCErhss0ZdF954Q0V62eh30qY8iAVZMVoZaYLyW+c62a/a2H7ahS6HTf9aBAB8JQP2TC1yfMwOEftWfcuTbribR9ReJsIIhMnEhnbmGEIkcvBFhc89YFsFTRQlTpPCH56dpAqXofd027t7FR/XFxqF8129iOtRZllx3GBGGKxJk1TIpFvjkdIcxxS1QQGAl/3/ra0AOSoqhfNRqtlDMm3YAMl1vbGRGdB3zKb/HHgu9a7H4tiCUE1cv7rwoB5fvUsiz6bdIN9XsePWFB5HfRlzAzeCSPL87vmz3jKNPNtm4v0hurvink5wc4n8OGAc+PlLpwoTEIhCGDx4TAPNMUcxuIxqUzZUWOKz1bBn03LNy+bcLTO8N+WgJ/wTyOe0zRB6EPcudOZSEOyBlKKU31N/R416TNsXfanJjn66ybf0VZDH+HOKv9rfjSbt/fPPJ9085VEs= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > -----Original Message----- > From: Barry Song <21cnbao@gmail.com> > Sent: Sunday, September 15, 2024 11:16 PM > To: Andre Glover > 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 > ; Jiang, Dave ; Feghali, = Wajdi K > ; Guilford, James = ; Gopal, > Vinodh ; Seshasayee, Bala > ; Caldwell, Heath = ; > Sridhar, Kanchana P ; 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 >=20 > On Thu, May 2, 2024 at 5:46=E2=80=AFAM Andre Glover = > 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. >=20 > Hi Andre, >=20 > I am definitely in favor of the patchset idea. However, I'm not = convinced that a > separate by_n API is necessary. Couldn=E2=80=99t this functionality be = handled > automatically within your driver? For instance, if a large folio is = detected, could it > automatically apply the by_n concept? >=20 > 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 = =E2=80=98by_n=E2=80=99 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