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:     Horia Geanta <horia.geanta@nxp.com>,
        Aymen Sghaier <aymen.sghaier@nxp.com>,
        "David S. Miller" <davem@davemloft.net>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        Gary Hook <gary.hook@amd.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 08/12] crypto: caam - support crypto_engine framework for
 SKCIPHER algorithms
Thread-Topic: [PATCH 08/12] crypto: caam - support crypto_engine framework for
 SKCIPHER algorithms
Thread-Index: AQHVnZa0/lOdW2TUXUqvGjTaL30gkA==
Date:   Fri, 22 Nov 2019 14:11:46 +0000
Message-ID: <VI1PR04MB444537DA6774BE5E31F2C04F8C490@VI1PR04MB4445.eurprd04.prod.outlook.com>
References: <1574029845-22796-1-git-send-email-iuliana.prodan@nxp.com>
 <1574029845-22796-9-git-send-email-iuliana.prodan@nxp.com>
 <20191122103309.wf2hg7km45ugzzhr@gondor.apana.org.au>
 <VI1PR04MB4445DACDF6F1AF1CDABC6E7A8C490@VI1PR04MB4445.eurprd04.prod.outlook.com>
 <20191122110915.f7rsqb4hnsg4pfci@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: 06d9a70f-4ac0-4765-2f80-08d76f55e8c3
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2019 14:11:46.2955
 (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: 680cLoUnK6L6bZu17OGy5+ur1e3F4cYRYPQFwWfRureRZV6uqW9ZzNpD6ULpn0BDsYoh+Hl2PjqSAXmFBDa4Ug==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB3997
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 11/22/2019 1:09 PM, Herbert Xu wrote:=0A=
> On Fri, Nov 22, 2019 at 11:05:59AM +0000, Iuliana Prodan wrote:=0A=
>>=0A=
>> Sorry, but I don't understand what is wrong here? I'm using the correct=
=0A=
>> type, the specific type, for the request when sending it to crypto engin=
e.=0A=
>> This transfer_request_to_engine function is called from caam_jr_enqueue,=
=0A=
>> where I have all types of request, so I'm using the async_request, and=
=0A=
>> when transferring to crypto engine I cast it to the specific type.=0A=
> =0A=
> These internal types are only for use by the crypto API and helper=0A=
> code such as crypto_engine.  They should not be used by drivers in=0A=
> general.=0A=
> =0A=
So, just to be clear, I shouldn't use crypto_async_request in driver code?=
=0A=
I see that this generic crypto request is used in multiple drivers.=0A=
=0A=
>> I believe is an overhead to sent all request to crypto engine since most=
=0A=
>> of them can be directly executed by hw.=0A=
>> Also, in case there is no need for backlog and the hw is busy we can=0A=
>> drop the request.=0A=
> =0A=
> If the crypto_engine has so much overhead then you should work on=0A=
> fixing crypto_engine and not work around it like this.=0A=
> =0A=
I can try sending _all_ requests to crypto engine and make some =0A=
performance measurements to see which solution is best.=0A=
=0A=
Thanks,=0A=
Iulia=0A=