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;
From:   Iuliana Prodan <iuliana.prodan@nxp.com>
To:     Herbert Xu <herbert@gondor.apana.org.au>
CC:     Baolin Wang <baolin.wang@linaro.org>,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        Corentin Labbe <clabbe.montjoie@gmail.com>,
        Horia Geanta <horia.geanta@nxp.com>,
        Maxime Coquelin <mcoquelin.stm32@gmail.com>,
        Alexandre Torgue <alexandre.torgue@st.com>,
        Maxime Ripard <mripard@kernel.org>,
        Aymen Sghaier <aymen.sghaier@nxp.com>,
        "David S. Miller" <davem@davemloft.net>,
        Silvano Di Ninno <silvano.dininno@nxp.com>,
        Franck Lenormand <franck.lenormand@nxp.com>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [RFC PATCH] Crypto-engine support for parallel requests
Thread-Topic: [RFC PATCH] Crypto-engine support for parallel requests
Thread-Index: AQHVz+nyH19jpegvq0OzoQlSx1aIPw==
Date:   Tue, 21 Jan 2020 10:08:53 +0000
Message-ID: <VI1PR04MB444594375C6CAAEE125C65C48C0D0@VI1PR04MB4445.eurprd04.prod.outlook.com>
References: <1579563149-3678-1-git-send-email-iuliana.prodan@nxp.com>
 <20200121091102.magzogr7tnj6joqm@gondor.apana.org.au>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7df4c1a5-3303-4ee7-8fbe-08d79e59eb79
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 10:08:53.4742
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: S5s5BcNcYQPNBhEyz0ReyGTPvBwFHoZZpz7S2St04TLLknBggMzrL1RQSw8jsNIsOF6jGmLCfRi5UHvY2Pq/9g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB4606
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

On 1/21/2020 11:11 AM, Herbert Xu wrote:=0A=
> On Tue, Jan 21, 2020 at 01:32:29AM +0200, Iuliana Prodan wrote:=0A=
>>=0A=
>> +	if (engine->no_reqs < engine->max_no_reqs)=0A=
>> +		goto retry;=0A=
> =0A=
> We should not hard-code this number into the engine.  Instead,=0A=
> we should just let the driver tell us when it is ready to accept=0A=
> more requests.=0A=
> =0A=
This is not hardcoded in crypto-engine.=0A=
I've added the crypto_engine_alloc_init_and_set function to configure =0A=
how crypto-engine works.=0A=
The max_no_req means how many request the driver can process in parallel.=
=0A=
If this doesn't apply on some drivers they can call =0A=
crypto_engine_alloc_init, which has max_no_req =3D 1 - this is the current =
=0A=
behavior. That is serialization of requests by crypto-engine which is a =0A=
bottleneck.=0A=
=0A=
> Perhaps we should add a new function for drivers that wish to=0A=
> support this that would accept a list of requests instead of=0A=
> a single one.  It would then process as many requests as it=0A=
> can from that list and only return either when the list is=0A=
> exhausted or when it can't process any more requests.=0A=
> =0A=
=0A=
Linking requests is something different that is not addressed by my =0A=
proposal.=0A=
I want to remove this serialization, done by crypto-engine, of unrelated =
=0A=
requests.=0A=