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:   Thu, 15 Sep 2022 14:09:11 +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: <YyMj9yKMSTC4Iw0s@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>
 <YwjW2x/uT9ST8+8i@gcabiddu-mobl1.ger.corp.intel.com>
 <Yw3TpwuF7a46SZDI@gondor.apana.org.au>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Yw3TpwuF7a46SZDI@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?bfJ3dJixbiYFOe+Wk8zV5ed+DRyvLy1Kp/qwnIWVvIMz03GodeJUrw1btPSj?=
 =?us-ascii?Q?hwddDeF/qJFZjzz7Awwj3pXFYwVuh5WVSnDdCSzDJFIQus6xU6bpG6PrI0B2?=
 =?us-ascii?Q?knUafCIul0dCXHHCdbDP0FHtXJ5hV0+pk7oQCIMksg+JCw15FhXKtVmsLhaK?=
 =?us-ascii?Q?tU+UAQmRipx/v7/X1uAQMCC1r9FJGMwRUBX6TJ6Ov8D9jc6B3Soz6X/v+OUf?=
 =?us-ascii?Q?D+slsO9Vq2pQmek7orIjw4C4hwzebz22TrZJDv6oBodenOWRwm2S1l4ZNiZw?=
 =?us-ascii?Q?Yv5nPGeJ8Ou4KvXtyk15r0BYvQbC3lOMP8Q2PZ2o3aHJZtNCFiRoH0shzHAF?=
 =?us-ascii?Q?nuj9EWqbbPeJ+/mXRAQKq6xCiszT0SoaKD9hUvRFA6BDCiGHLhA7s0uyOAaJ?=
 =?us-ascii?Q?iEUuVIeutTHNMuDMfauHpZDRngF/dXOx0IVIhTks+jB2MHXtpLEsnhKEwK6o?=
 =?us-ascii?Q?lDDttYmgOkVk+NgKMTkUCswUogNu0xSa5zpcGdR1yb3lFf8WTtbTekqctRsh?=
 =?us-ascii?Q?5lY1x8Qt5A3fFpcemuMDB5nxWSd0EeYGQXqOAMWtEVZ/HN1oLkF7Kf2t475A?=
 =?us-ascii?Q?nPaDBT6K35whtkIAmB9qW/Kr8xr6yOiH5CeQAmjQfmv3r+HVe4Dz6sMJD2Wg?=
 =?us-ascii?Q?CS6O5VmQaxOhyuj0pZe1JLad3Y2N8jL6KCbLkdeljNKz2oNs/dfDZQTPWVkI?=
 =?us-ascii?Q?wg+lMPoSW66ezAfAK1h1QhDHUbWs6MaDDC6rJKmazGYP13/jCGuSBZmN3ZQU?=
 =?us-ascii?Q?7vrgjfduiR7ZT2Opd46zwCXrklA8z1xLeJR7bnNTNrkB1gBy86A/pIaJpVI9?=
 =?us-ascii?Q?J48oNylnCcP6klYd6AzC6eEI92TrcAKBCDfrD0pxjYrVLr54jtGM0n4l5l2P?=
 =?us-ascii?Q?5tLNoFyfZhSqTS9xqhe0zsY025p0UpVbFpUGgHh1e7EsYPrbstD5WmnlpPrL?=
 =?us-ascii?Q?yCQW/N0LH2kyBrVS9PMA5gJiFE6CeRZlznGj1KDkT7mflco2Rw+f3iV4fOqC?=
 =?us-ascii?Q?JEj2sFcrNatkddrnZ7XN6d764w8sssFXnxOfKPdDXEIk9I/EUEaicgVuW6zT?=
 =?us-ascii?Q?kWbowzIgIiX0qERq83u+W/pX44dfJ5zEISvlXnue2P9ERef2qZF4Z+JTnf9V?=
 =?us-ascii?Q?BODSvpZnfGkiqDDV3vyHjvNdap8DxCpEVzTj/7fMdD1TF120sSFslPs0q9gb?=
 =?us-ascii?Q?BsKyhsduoZQzsTuiG3/pQHqmtMFLWcO6bthRg1gf+fDQT8rN6THDfF0vP/Iu?=
 =?us-ascii?Q?PG4VaBvm20MP7+yG0priha5OXwJftPjqKSZZRHdFr+/W+q16mqh/SC580xvj?=
 =?us-ascii?Q?twr1WmeRnq3X56kgtzczyy/SnJYsgqEDbbqqaCXgmv5TNslr/CFD7Nd0u9p3?=
 =?us-ascii?Q?EKZkwoOgmt5Fbm3YxO/iaFoUArINI8wkqFgYsBSK2g4DQZxQvgVVgkZMe6kJ?=
 =?us-ascii?Q?u8nIkUqPLbYRsunm8VY+3QUpOI9z5naEHul5k8LUXmJ2jBhpWJOXdI7rVslf?=
 =?us-ascii?Q?Y+r+nNprXYekw8BOE9danXMJsbEjlgorRUTsL+u0w11qZ5Epki0SxNL9zH78?=
 =?us-ascii?Q?MQecsXJAuyq9zUJbA/oLBcFkAkVsl7fu5yvhSC0ToMjfubC8HdT6yqJmnVzj?=
 =?us-ascii?Q?zg=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: e2556187-fa40-4c03-6169-08da971b7f19
X-MS-Exchange-CrossTenant-AuthSource: CY5PR11MB6366.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2022 13:09:18.0814
 (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: J0fIwnEEQbJHgG3hITvqClR8JIJDpcTR4xPNng5pIg8VO1NqygYMaEw4l+y8drTxT8b2TISgQCio2O6UG/kvRrLsHbVwD+zr88nFXwCCYZU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7290
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE
        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

Hi Herbert,

On Tue, Aug 30, 2022 at 05:08:55PM +0800, Herbert Xu wrote:
> 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.
I prototyped the solution you proposed and it introduces complexity,
still doesn't fully solve the problem and it is not performant. See
below*.

We propose instead to match the destination buffer size used in scomp
for the NULL pointer use case, i.e. 128KB:
https://elixir.bootlin.com/linux/v6.0-rc5/source/include/crypto/internal/scompress.h#L13
Since the are no users of acomp with this use-case in the kernel, we
believe this will be sufficient.

Can we go with this solution since we have a user waiting for the acomp
implementation in the qat driver?

*Brief description of the prototyped solution:
When the callback detects an overflow condition on a request with a NULL
destination buffer, it schedules a new workqueue. This is since the
callback is running in the context of a tasklet and we want to avoid
atomic allocations.
The workqueue allocates additional pages for the destination buffer, map
those pages, re-construct the FW destination buffer list and re-send the
request to the device, making sure that the request is actually
enqueued.

Regards,

-- 
Giovanni