Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp746701ybz; Wed, 15 Apr 2020 18:04:24 -0700 (PDT) X-Google-Smtp-Source: APiQypKyeolhy3bupiR2WLIrGRBIUVn61bKbBWUHz0oX2S+YbQ0nYJ739MYJI6uPpuY4OyUwQZGF X-Received: by 2002:a05:6402:28b:: with SMTP id l11mr21721643edv.156.1586999064174; Wed, 15 Apr 2020 18:04:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586999064; cv=none; d=google.com; s=arc-20160816; b=bp7Bv2C+2iRVt0VZgipPbqHMu26tMVQfp/ic0WuEiyySCZGzpwbcL3Tn722jLD+na+ Ig7FYN+VBhhOavIZXygrwK8E67fhVjCekYzA6JCUVo8GltqI4R7HobkNrcf6IpA13khQ cO/JD98jnRX0ZfX6RB+NylM2Jx93rSKBE6v7D7SPyTt6AVqESNTm9BiKpcUcmsqkymhF ZCrKwiD2HkC4qPB+9eSGqLShvJf0y+aK1qwC1xnlJ5AkJ25TaR54mG/V7XyOSsTIyzJi 1f4VjFim2ihVsQ7w7RKV5XeQCD4rNz6CSNOTV6x31FEpOS+7+baaPfA8SHZSkzf4CEmA N8pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=NKwoVP94+fumHTxkPmZtfhOXL1esIGRp+NdxA/16zwk=; b=g7jT/7Dhq7459NcviPf6i3gS4bZcsLPLnomOzkP793rW3DhA+/2/3DL0V3oxgmAgZF hw12I8KLVWYsA930ChPbnIzw5VibLrGLKI76ydijhy8z68FzcXcKkkftSuAc+sOFrUkV YteOFgXMLKd4M6zDzFpDGsdqml3FOY9b6I6xkSjiibdgqR3omFY3QGVMhwDWCQJ4n00P iTt+M+xkRPSh+n8S3sOoVj33HQ6E7TTKjWXa872vJufQ3dQYi84ivSUTAEJECaRsWNDr uAu1sO++ckGML2oCfQbOyW3tsk0vGbVUtzPqvHMIHS/zdbgssHQ86EosC5DQ4g3vRNfN r5+Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nxp.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r21si10731700ejo.82.2020.04.15.18.03.53; Wed, 15 Apr 2020 18:04:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437812AbgDOU0k (ORCPT + 99 others); Wed, 15 Apr 2020 16:26:40 -0400 Received: from inva020.nxp.com ([92.121.34.13]:54462 "EHLO inva020.nxp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2406376AbgDOU03 (ORCPT ); Wed, 15 Apr 2020 16:26:29 -0400 Received: from inva020.nxp.com (localhost [127.0.0.1]) by inva020.eu-rdc02.nxp.com (Postfix) with ESMTP id C6DDC1A0A1B; Wed, 15 Apr 2020 22:26:23 +0200 (CEST) Received: from inva024.eu-rdc02.nxp.com (inva024.eu-rdc02.nxp.com [134.27.226.22]) by inva020.eu-rdc02.nxp.com (Postfix) with ESMTP id AF7A71A0A17; Wed, 15 Apr 2020 22:26:23 +0200 (CEST) Received: from lorenz.ea.freescale.net (lorenz.ea.freescale.net [10.171.71.5]) by inva024.eu-rdc02.nxp.com (Postfix) with ESMTP id D3E4420506; Wed, 15 Apr 2020 22:26:22 +0200 (CEST) From: Iuliana Prodan To: Herbert Xu , Baolin Wang , Ard Biesheuvel , Corentin Labbe , Horia Geanta , Maxime Coquelin , Alexandre Torgue , Maxime Ripard Cc: Aymen Sghaier , "David S. Miller" , Silvano Di Ninno , Franck Lenormand , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, linux-imx , Iuliana Prodan Subject: [PATCH v5 0/3] crypto: engine - support for parallel and batch requests Date: Wed, 15 Apr 2020 23:26:12 +0300 Message-Id: <1586982375-18710-1-git-send-email-iuliana.prodan@nxp.com> X-Mailer: git-send-email 2.1.0 X-Virus-Scanned: ClamAV using ClamSMTP Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Added support for executing multiple, independent or not, requests for crypto engine based on a retry mechanism. If hardware was unable to execute a backlog request, enqueue it back in front of crypto-engine queue, to keep the order of requests. Now do_one_request() returns: >= 0: hardware executed the request successfully; < 0: this is the old error path. If hardware has support for retry mechanism, the backlog request is put back in front of crypto-engine queue. For backwards compatibility, if the retry support is not available, the crypto-engine will work as before. Only MAY_BACKLOG requests are enqueued back into crypto-engine's queue, since the others can be dropped. If hardware supports batch requests, crypto-engine can handle this use-case through do_batch_requests callback. Since, these new features, cannot be supported by all hardware, the crypto-engine framework is backward compatible: - by using the crypto_engine_alloc_init function, to initialize crypto-engine, the new callback is NULL and retry mechanism is disabled, so crypto-engine will work as before these changes; - to support multiple requests, in parallel, retry_support variable must be set on true, in driver. - to support batch requests, do_batch_requests callback must be implemented in driver, to execute a batch of requests. The link between the requests, is expected to be done in driver, in do_one_request(). --- Changes since V4: - added, in algapi a function to add a request in front of queue; - added a retry mechanism: if hardware is unable to execute a backlog request, enqueue it back in front of crypto-engine queue, to keep the order of requests. Changes since V3: - removed can_enqueue_hardware callback and added a start-stop mechanism based on the on the return value of do_one_request(). Changes since V2: - readded cur_req in crypto-engine, to keep, the exact behavior as before these changes, if can_enqueue_more is not implemented: send requests to hardware, _one-by-one_, on crypto_pump_requests, and complete it, on crypto_finalize_request, and so on. - do_batch_requests is available only with can_enqueue_more. Changes since V1: - changed the name of can_enqueue_hardware callback to can_enqueue_more, and the argument of this callback to crypto_engine structure (for cases when more than ore crypto-engine is used). - added a new patch with support for batch requests. Changes since V0 (RFC): - removed max_no_req and no_req, as the number of request that can be processed in parallel; - added a new callback, can_enqueue_more, to check whether the hardware can process a new request. Iuliana Prodan (3): crypto: algapi - create function to add request in front of queue crypto: engine - support for parallel requests based on retry mechanism crypto: engine - support for batch requests crypto/algapi.c | 11 +++ crypto/crypto_engine.c | 165 ++++++++++++++++++++++++++++++++-------- include/crypto/algapi.h | 2 + include/crypto/engine.h | 15 +++- 4 files changed, 161 insertions(+), 32 deletions(-) -- 2.17.1