Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp608924ybv; Wed, 5 Feb 2020 11:11:59 -0800 (PST) X-Google-Smtp-Source: APXvYqzwCnSrheJDy+yEwWYuIJJorpNAhPGTucJoHQzAO4bBcoepbfk5qZdD+T4zPf6ByxxFbB10 X-Received: by 2002:aca:1c1a:: with SMTP id c26mr4162957oic.75.1580929919136; Wed, 05 Feb 2020 11:11:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580929919; cv=none; d=google.com; s=arc-20160816; b=hBpXrrteJ3+omPp+hCAnnXewr4nNSpDxufFfepvU21dCYwJQ3CgGhRnnvpkmtnNiba ytqRMJRgktsGVk4X1qFeqMvHDiBKtVK0b+r8W/MuSQcbvkudg2VieSnn6YrZeR0kMgSy QhPxAypVsOa0evaAEaENUs5CfP2N8WSTkI1zyZiIR+otFSsiVl2v37s9IMUfrbr8+3AN x9T+45ZjN5sa2nRmezs3UA1POUy3NWirKBEKwulqpt13prnN9jU2QGgm2+8r9nnPAagk ZJjsCy7gQQTxfbN5ULUl6IjKjWqLNDzTQJxMGFdGu4hJ1AgPGlPhyxTfw6B8CRotP+s/ Oc/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=jMov4KbETyM2WMoQRxMlok3LUpvFHoRjtuVdQssH7qc=; b=QrlpgHzUZlH2PPEQRHa4OjUfZLylA1tndWoeEOAXlbR4de1t2Q96Kx2QVbZWGdPGPU WXVHbdcSLpnY61GNEsYcxeXDq2uQ645ibfN2q/X8x+JWVbKr5+oTJrzuqUnJ2LA5L6iH /c6bEgSpTMDTr3MhuH9AbeBFe1JheDyX1JPKpV9Itb0aXZhdrPgVR8xfpq0igDg/mL4/ Bfxh1qPgFJW8b17nAZg7gUrbkIWU1/N83JrvC/YvWH/DzK6zhRiTx/QbjCHrAzTScrd8 79wuOEKsglpZ0I5+e6ea2QxOlmjyBlqgY1E1c923RXGDpo4n+fQNFa7aFQ6+/kpWj7W1 H/9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MFyyiATY; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a194si605406oib.227.2020.02.05.11.11.36; Wed, 05 Feb 2020 11:11:59 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MFyyiATY; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727033AbgBETLd (ORCPT + 99 others); Wed, 5 Feb 2020 14:11:33 -0500 Received: from mail-wm1-f66.google.com ([209.85.128.66]:38175 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727085AbgBETLd (ORCPT ); Wed, 5 Feb 2020 14:11:33 -0500 Received: by mail-wm1-f66.google.com with SMTP id a9so4172694wmj.3; Wed, 05 Feb 2020 11:11:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=jMov4KbETyM2WMoQRxMlok3LUpvFHoRjtuVdQssH7qc=; b=MFyyiATYYDslQazdI+M1S6zJoUcmUuu2qGCEfjYlAdSm15sFBeMhqZaKgqFxh5mCXr mkNyVuWGVZG8Xa1XmMzL1Lf0iLW90BxQy3mZafy179P49bOPTMs1jRqQ+GZMGdJBrxSu urkC8c1SqBYoxzLw6ptMLn6kJ1zpZx+8LudsTT2LiOr4M6Fe6RpKogzDWI593bKhQVqI 3M/AIrObzFSC4PbLLD0QrVVuiM/1hfERWgqE8woiBpC+kAfcgjzqpOTNXlCFB0C1I6X6 xmgnt2UA6FmE5qhRVgjpUoLizW6TfRkrm3Q+8LdbjY+ofIzRS4C2qhRrJ1QwQgNI3tkd pJXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=jMov4KbETyM2WMoQRxMlok3LUpvFHoRjtuVdQssH7qc=; b=gRg9jZf9aEr/5MbUYRrGojnLdDAIbtGhEMBd3DX2Q2vx+KepGaQt6+LFRhtnfxNV7p I9JlY6xJXbfTHIW/ZovoQgqsZPTK6lPZb26JzTayJS/67CDte8V6M72aPK7FCeUB9Y6S cAbDU9cv+YBZCJFxJqwQur/oOn+k/n3SOC8brL2vvBKPbPsBilN/eLqK5q9OXEdLyMRy 1q72uwKmzZtYL/vfZdsc9Q7dTfKWQ42ZmAOed3YfkPlAzl6YRPPNx44vKKng1Obcc3Gd KZ4AajAxEQxW5/YwfZCngm2UwW8/UHLLPBMdbztjxyiTvCpqeD/dYvjVN6bVnsSH16/l 7RJQ== X-Gm-Message-State: APjAAAWVW56p/EVbs1ZLMnkioalpFEYyCYRooLPYA1dsqRc0H59APd/T 3yOzpmgiJXRkFGCEnnE9HDQ= X-Received: by 2002:a7b:c934:: with SMTP id h20mr7155581wml.103.1580929890748; Wed, 05 Feb 2020 11:11:30 -0800 (PST) Received: from Red ([2a01:cb1d:3d5:a100:2e56:dcff:fed2:c6d6]) by smtp.googlemail.com with ESMTPSA id y17sm917898wrs.82.2020.02.05.11.11.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Feb 2020 11:11:30 -0800 (PST) Date: Wed, 5 Feb 2020 20:11:28 +0100 From: Corentin Labbe To: Iuliana Prodan Cc: Herbert Xu , Baolin Wang , Ard Biesheuvel , Horia Geanta , Maxime Coquelin , Alexandre Torgue , Maxime Ripard , Aymen Sghaier , "David S. Miller" , Silvano Di Ninno , Franck Lenormand , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, linux-imx Subject: Re: [PATCH v2 1/2] crypto: engine - support for parallel requests Message-ID: <20200205191128.GA32606@Red> References: <1580819660-30211-1-git-send-email-iuliana.prodan@nxp.com> <1580819660-30211-2-git-send-email-iuliana.prodan@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1580819660-30211-2-git-send-email-iuliana.prodan@nxp.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Tue, Feb 04, 2020 at 02:34:19PM +0200, Iuliana Prodan wrote: > Added support for executing multiple requests, in parallel, > for crypto engine. > A new callback is added, can_enqueue_more, which asks the > driver if the hardware has free space, to enqueue a new request. > The new crypto_engine_alloc_init_and_set function, initialize > crypto-engine, sets the maximum size for crypto-engine software > queue (not hardcoded anymore) and the can_enqueue_more callback. > On crypto_pump_requests, if can_enqueue_more callback returns true, > a new request is send to hardware, until there is no space and the > callback returns false. > > Signed-off-by: Iuliana Prodan > --- > crypto/crypto_engine.c | 106 ++++++++++++++++++++++++++++++------------------ > include/crypto/engine.h | 10 +++-- > 2 files changed, 72 insertions(+), 44 deletions(-) > > diff --git a/crypto/crypto_engine.c b/crypto/crypto_engine.c > index eb029ff..aba934f 100644 > --- a/crypto/crypto_engine.c > +++ b/crypto/crypto_engine.c > @@ -22,32 +22,18 @@ > * @err: error number > */ > static void crypto_finalize_request(struct crypto_engine *engine, > - struct crypto_async_request *req, int err) > + struct crypto_async_request *req, int err) > { > - unsigned long flags; > - bool finalize_cur_req = false; > int ret; > struct crypto_engine_ctx *enginectx; > > - spin_lock_irqsave(&engine->queue_lock, flags); > - if (engine->cur_req == req) > - finalize_cur_req = true; > - spin_unlock_irqrestore(&engine->queue_lock, flags); > - > - if (finalize_cur_req) { > - enginectx = crypto_tfm_ctx(req->tfm); > - if (engine->cur_req_prepared && > - enginectx->op.unprepare_request) { > - ret = enginectx->op.unprepare_request(engine, req); > - if (ret) > - dev_err(engine->dev, "failed to unprepare request\n"); > - } > - spin_lock_irqsave(&engine->queue_lock, flags); > - engine->cur_req = NULL; > - engine->cur_req_prepared = false; > - spin_unlock_irqrestore(&engine->queue_lock, flags); > + enginectx = crypto_tfm_ctx(req->tfm); > + if (enginectx->op.prepare_request && > + enginectx->op.unprepare_request) { > + ret = enginectx->op.unprepare_request(engine, req); > + if (ret) > + dev_err(engine->dev, "failed to unprepare request\n"); > } > - > req->complete(req, err); > > kthread_queue_work(engine->kworker, &engine->pump_requests); > @@ -73,10 +59,6 @@ static void crypto_pump_requests(struct crypto_engine *engine, > > spin_lock_irqsave(&engine->queue_lock, flags); > > - /* Make sure we are not already running a request */ > - if (engine->cur_req) > - goto out; > - Hello Your patch has the same problem than mine reported by Horia. If a queue has more than one request, a first crypto_pump_requests() will send a request and for drivers which do not block on do_one_request() crypto_pump_requests() will end. Then another crypto_pump_requests() will fire sending a second request while the driver does not support that. So we need to replace engine->cur_req by another locking mechanism. Perhaps the cleaner is to add a "request count" (increased when do_one_request, decreased in crypto_finalize_request) I know that the early version have that and it was removed, but I do not see any better way. Regards