Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 26 Aug 2022 15:21:15 +0100
From:   Giovanni Cabiddu <giovanni.cabiddu@intel.com>
To:     Herbert Xu <herbert@gondor.apana.org.au>
CC:     <linux-crypto@vger.kernel.org>, <qat-linux@intel.com>,
        Vlad Dronov <vdronov@redhat.com>,
        Wojciech Ziemba <wojciech.ziemba@intel.com>,
        "Adam Guerin" <adam.guerin@intel.com>
Subject: Re: [PATCH 8/9] crypto: qat - expose deflate through acomp api for
 QAT GEN2
Message-ID: <YwjW2x/uT9ST8+8i@gcabiddu-mobl1.ger.corp.intel.com>
References: <20220818180120.63452-1-giovanni.cabiddu@intel.com>
 <20220818180120.63452-9-giovanni.cabiddu@intel.com>
 <YwigYBNM7O/J6gO1@gondor.apana.org.au>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <YwigYBNM7O/J6gO1@gondor.apana.org.au>
Organization: Intel Research and Development Ireland Ltd - Co. Reg. #308263 -
 Collinstown Industrial Park, Leixlip, County Kildare - Ireland
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?liWp+1RHbvsBWdgDBcJLU/AH6LOt3XFaroR8MAqCCibYFw5/rhULCZGZcolv?=
 =?us-ascii?Q?Kxmt6FWm8EeVYhUAXpyOO1n7eK+/yu0YZlsSdcN6bBUGjOnhg7JgCRRHEG5N?=
 =?us-ascii?Q?P3CQLeh99erMCUDQNNA0WQkBaASdDJmCKKu6CqVA8i23NP0Gn+S3YdzTu6YF?=
 =?us-ascii?Q?vjkkx1qIjKGvEBuKyTGNQri3dMSgwTI84Ik5e592BWciDFcbX8X56ODi0fXC?=
 =?us-ascii?Q?TNsEuTeO0MRzfiV5Rfu42ML8qjkUkVcOrNvBPQPNhhal8bzLQ5h7ZO9l/fDz?=
 =?us-ascii?Q?ThdG7H9GR6lJsuyjheURavmgFpx3sqjKw2opjCHjuonFUF0UXIRKLE2NwYDu?=
 =?us-ascii?Q?VfnF4ll7EMVmtEv84EVJ5/hUEKtqgjKLnod0o/2tidbNWEHq9SXvU6XYc03T?=
 =?us-ascii?Q?a66YXeuwXuYix+AS0ctU3ZbKyhL+7pD7KgwBUgeQU9wniOKtTxGJGCnJFnBH?=
 =?us-ascii?Q?zHaadOz64qHw1ChU4DUW/5SFiSmIG6Yz954GhjrpoGDC35duep45I0qcgu5e?=
 =?us-ascii?Q?KumpI4imn05Pz/q4VJinOtDD1j1jImIZx/9kb1vM60wPlJ9wJ+Mo0acoqQCN?=
 =?us-ascii?Q?aME4Y53VasSYeSAd9aa/uQi44gABod/8nFmtNJJQj1GFnLjNrbMg1EwiGKGN?=
 =?us-ascii?Q?bN96sk4FuwIfmLoXbV9qnxYE6nwXbCb71OJT0YGxBr3fe9c7yyuAAy9aLBrq?=
 =?us-ascii?Q?ldRtorOo7dnijkS+ZsB2vluujra/T22jwKs4ydh6nYqueE2WjnsR+agT6hyE?=
 =?us-ascii?Q?XzFifjAags0CPDcLE8uUF9B9skaeD1gWSHkTGboj4RhTCKsqgZ/jujbzoAKX?=
 =?us-ascii?Q?gd2WYrTboNaI9cLsYSlQK8gGpsYQN2Z4deFfwgFP/hoXO8SmdpYhS3RJgGc/?=
 =?us-ascii?Q?0caAg5EIvXJ2g8OyK347hUmMxRyLz+45uEsf3Yi+Zc2zsnascZE/sw/r2PM9?=
 =?us-ascii?Q?rPYC/damUUacs9uyFdJitlfxYE6uqequEANhm9MpDes+YB4yAUj+mI7HpeKn?=
 =?us-ascii?Q?ml8OHIZ3yjmorp0lLd/9kNqtHp+STfBfbZ4sNxHXaEJ2FXdzW0Lg00zjBVEi?=
 =?us-ascii?Q?8/aoWZDPJj8Kdqup3Xqg34eHVfo58RVEshSai5KXcT/JqhwTrZ3i47itlP19?=
 =?us-ascii?Q?GdbGlcO5fGakwRah4XEIGj8C0OpR3q2Py5JwUJRVj48gUqo47YGgmL+7yQ4m?=
 =?us-ascii?Q?8UBqRm79HHFRCUiVURDh/xIRT9ym/TNXZ/ZEcsmt8xL2jJTghFcLBMZqd/jg?=
 =?us-ascii?Q?EPVWVFWaBfU2lKJRfc2b5dmOSDwTF6FtXmDyuJC40ZEc38oQALEzqQxsUHNX?=
 =?us-ascii?Q?SZHb7b+JteptnFjczm9MT+6iNAUNAJiU6X4akYwKrIGWisf+lqjtY1rcNboX?=
 =?us-ascii?Q?TYM0R28bhVuUIDrouPSlSIMDyjxgi9bysJ1rjEEMnV2lj4nKM8sqNDu3tfpc?=
 =?us-ascii?Q?+PnVFVNm/QVsI0nl0kc/zPZkXsQuxKGObr8FGWfqV5v4zOismyxumhhw13Yf?=
 =?us-ascii?Q?+Jrct4zXdprUdfumUHAz/JPVDUyzpUuXxiAcZ9FBuiVXxGQa5lxI1w2oQico?=
 =?us-ascii?Q?vDKGXI4WpsuvnTrLgr1ayLEyzPrlYsUU0JnWhndwYLl7zLVQwoh1G/qeO+P0?=
 =?us-ascii?Q?/Q=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 104ce78e-5c9a-4a4e-b462-08da876e42c1
X-MS-Exchange-CrossTenant-AuthSource: CY5PR11MB6366.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2022 14:21:26.4833
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: evX9VSNjYJz/eWQYFXH+RmYHLxHDi6mAjHtKK6lcOhfItLDAqNYgTjDHAhLUaa1C6CeIoasagSc0Xwy47E8v5sr2Qtd3fJSHGLPLPijXGkQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3516
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

On Fri, Aug 26, 2022 at 06:28:48PM +0800, Herbert Xu wrote:
> On Thu, Aug 18, 2022 at 07:01:19PM +0100, Giovanni Cabiddu wrote:
> >
> > +	/* Handle acomp requests that require the allocation of a destination
> > +	 * buffer. The size of the destination buffer is double the source
> > +	 * buffer to fit the decompressed output or an expansion on the
> > +	 * data for compression.
> > +	 */
> > +	if (!areq->dst) {
> > +		dlen = 2 * slen;
> > +		areq->dst = sgl_alloc(dlen, f, NULL);
> > +		if (!areq->dst)
> > +			return -ENOMEM;
> > +	}
> 
> So what happens if the decompressed result is more than twice as
> long as the source?
The QAT HW will report that the destination buffer is not sufficiently
large to store the decompressed result and the job will fail with an
error and with dlen=0.

From the use case described in this thread [1], an option would be to
allocate always 64KB, i.e. IPCOMP_SCRATCH_SIZE [2].
Alternatively, allocate twice the source rounded up to 64KB:

#define MIN_DST_BUFFER_SZ 65536
    if (!areq->dst) {
        dlen = 2 * slen;
	dlen = dlen < MIN_DST_BUFFER_SZ ? MIN_DST_BUFFER_SZ : dlen;
	...
    }

What do you think?

It would be nice if the user of the api could provide a hint for the
size of the destination buffer in acomp_req.dlen.

Regards,

-- 
Giovanni

[1] https://lore.kernel.org/all/20160923150518.GA20384@gondor.apana.org.au/
[2] https://elixir.bootlin.com/linux/latest/source/include/net/ipcomp.h#L7