Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp3978703rwe; Tue, 30 Aug 2022 02:17:36 -0700 (PDT) X-Google-Smtp-Source: AA6agR4eUWTpmlLQv+37ol87uJ95SUmkVj77GzrRyDznUBv+Ie6TFXSIwR5dATbKAvMfLNhHjUyW X-Received: by 2002:aa7:c956:0:b0:43b:206d:c283 with SMTP id h22-20020aa7c956000000b0043b206dc283mr19505838edt.381.1661851056035; Tue, 30 Aug 2022 02:17:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661851056; cv=none; d=google.com; s=arc-20160816; b=sFvt7Qs8dz3nSn918fWOmeCgfpsZG3Fmvvj/taa1OLXQpNZCvJmp9fRJRteR8BMlH6 r/Yt7t9fb+1cdjlgLSatrFI8aeC8pJaC3OG1h2gn+wEjVaVCHur42YVn5T6JRW3TEeWJ 5Gv97jNmk8cVftA9058SjxXjLteLiYu+eUoWXVeOdZKo2DyzhbAxPeTVndLuuDWs8+zY Y5CrN/o2BVB+PnivaoD/TNngd1cE8KAbS2g8WhnaYfaKlaC5Ye09f7fQ/lHJGOd/BlQB j1UwZaAnvozDof59E12O0th855L9rKDbiCLfElp0lFmQSgPX9vvOR/eXJwDmv8ytpGAN 2jnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=/s0r0ygqOKVpBEQViLjneSSrmTqCQSr5VODwma0yqzQ=; b=hDE77WEQlPBM5VCSqbPHjaB1Y8GfEnwOUFDa4hz3IRS9gSEvdM4o/SqrMUmk5KATH9 qZyBSUiOBmUy83xwA+6xq4k74oLofM277P6yUZh4WgbFj1SwCH/wb5yYVonzEYE18cMo mOC8jKdiLSmqcRTvZx+3FMyfqiC4ftYmEHP3Od6OmgD30h0tp3y91+HoulZNEjhIawFT UzVvfSFlMEFZlUfPGoiwhFqtD5OcUI+V7xwH667eLRMtZF6VrCRbBk/x+eqIABXEiQPs 0g3K509WhFCtDLM3DWUsqSlAcKNdGk5aaOXl6VAxfEItzm6aMIqwLtnfAFvhhjWwOHnv 70OA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id wv13-20020a170907080d00b0073c14b6560bsi8567875ejb.177.2022.08.30.02.17.10; Tue, 30 Aug 2022 02:17:36 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230105AbiH3JJD (ORCPT + 99 others); Tue, 30 Aug 2022 05:09:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229747AbiH3JJC (ORCPT ); Tue, 30 Aug 2022 05:09:02 -0400 Received: from fornost.hmeau.com (helcar.hmeau.com [216.24.177.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6C6A3A8965 for ; Tue, 30 Aug 2022 02:09:01 -0700 (PDT) Received: from gwarestrin.arnor.me.apana.org.au ([192.168.103.7]) by fornost.hmeau.com with smtp (Exim 4.94.2 #2 (Debian)) id 1oSxEt-00GeeE-Os; Tue, 30 Aug 2022 19:08:56 +1000 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Tue, 30 Aug 2022 17:08:55 +0800 Date: Tue, 30 Aug 2022 17:08:55 +0800 From: Herbert Xu To: Giovanni Cabiddu Cc: linux-crypto@vger.kernel.org, qat-linux@intel.com, Vlad Dronov , Wojciech Ziemba , Adam Guerin Subject: Re: [PATCH 8/9] crypto: qat - expose deflate through acomp api for QAT GEN2 Message-ID: References: <20220818180120.63452-1-giovanni.cabiddu@intel.com> <20220818180120.63452-9-giovanni.cabiddu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS,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: X-Mailing-List: linux-crypto@vger.kernel.org On Fri, Aug 26, 2022 at 03:21:15PM +0100, Giovanni Cabiddu wrote: > > 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. The whole point of this is that the user has no idea how big the result will be. If anyone would have a clue, it would be whoever is doing the decompression. Ideally the hardware would take an SG list, dump whatever result that fits into it, and then stop the decompression, dump the interim state somewhere so that it can be resumed, ask for memory from the driver, and then resume the decompression. I understand that hardware already exists that cannot perform such an incremental process. In that case we should hide this inadequacy in the driver. Here's a suggestion. Start with whatever value you want (e.g., src * 2), attempt the decompression, if it fails because the space is to small, then double it and retry the operation. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt