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: [PATCH v4 1/2] crypto: engine - support for parallel requests
Thread-Topic: [PATCH v4 1/2] crypto: engine - support for parallel requests
Thread-Index: AQHV9ZwplCPBsoqUKkWl+/E0XiXZQA==
Date:   Tue, 17 Mar 2020 13:08:18 +0000
Message-ID: <VI1PR0402MB3712DC09FC02FBE215006C5B8CF60@VI1PR0402MB3712.eurprd04.prod.outlook.com>
References: <1583707893-23699-1-git-send-email-iuliana.prodan@nxp.com>
 <1583707893-23699-2-git-send-email-iuliana.prodan@nxp.com>
 <20200312032553.GB19920@gondor.apana.org.au>
 <AM0PR04MB71710B3535153286D9F31F8B8CFD0@AM0PR04MB7171.eurprd04.prod.outlook.com>
 <20200317032924.GB18743@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: 9669300d-e2f4-48b0-d251-08d7ca7442d9
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2020 13:08:18.1643
 (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: 4MMY4N29Isba6Hr5bz9FPTcE5oCA5tJGLMaGkXii47dKQFiSjVtSihiQfi3nLNX/N9+KcBWY3cYyp5uAZ0fCHA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0402MB3439
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 3/17/2020 5:29 AM, Herbert Xu wrote:=0A=
> On Thu, Mar 12, 2020 at 12:45:54PM +0000, Iuliana Prodan wrote:=0A=
>>=0A=
>> There are two aspects here:=0A=
>> - if all requests go through crypto-engine, and, in this case, if there=
=0A=
>> is no space in hw queue, do_one_req returns 0, and actually there will=
=0A=
>> be no case of do_one_request() < 0;=0A=
> =0A=
> OK, that makes sense.  However, this way of signaling for more=0A=
> requests can be racy.  Unless you can guarantee that the driver=0A=
> is not taking any requests from another engine queue (or any=0A=
> other source), just because it returned a positive value now does=0A=
> not mean that it would be able to take a request the next time=0A=
> you come around the loop.=0A=
> =0A=
=0A=
This case can happen right now, also. I can't guarantee that all drivers =
=0A=
send all requests via crypto-engine.=0A=
This is the second aspect from my other mail. There are cases, when we =0A=
send requests (non crypto API) to hardware without passing to crypto-engine=
.=0A=
=0A=
To solve this, I'm thinking of adding new patches that doesn't do =0A=
request dequeue from crypto-engine queue, just peek, and dequeues the =0A=
request after was successfully executed by hardware (if it has =0A=
MAY_BACKLOG flag, otherwise will dequeue it). What do you think?=0A=
=0A=
Also, the above modification will imply changes in the drivers that use =0A=
crypto-engine.=0A=
=0A=
Thanks,=0A=
Iulia=0A=
=0A=
>> I've tried this, but it implies modifications in all drivers. For=0A=
>> example, a driver, in case of error, it frees the resources of the=0A=
>> request. So, will need to map again a request.=0A=
> =0A=
> I think what we are doing here is a major overhaul to the crypto=0A=
> engine API so while it's always a good idea to minimise the impact,=0A=
> we should not let the existing drivers constrain us too much.=0A=
> =0A=
> Thanks,=0A=
> =0A=
=0A=