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 11:05:59 +0000
Message-ID: <VI1PR04MB4445DACDF6F1AF1CDABC6E7A8C490@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>
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: 2110a36d-a19e-4a74-4748-08d76f3bf4dc
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2019 11:05:59.6981
 (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: 5uxO4bFcV4wWh3STKH0KcnY4Zw7hm92mad3KoDr2ZM1/3TWLIxj5zrF0oKsTYqxCkLiHlFv/seQ4bG0JrFVIjQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB4206
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 12:33 PM, Herbert Xu wrote:=0A=
> On Mon, Nov 18, 2019 at 12:30:41AM +0200, Iuliana Prodan wrote:=0A=
>>=0A=
>> +static int transfer_request_to_engine(struct crypto_engine *engine,=0A=
>> +				      struct crypto_async_request *req)=0A=
>> +{=0A=
>> +	switch (crypto_tfm_alg_type(req->tfm)) {=0A=
>> +	case CRYPTO_ALG_TYPE_SKCIPHER:=0A=
>> +		return crypto_transfer_skcipher_request_to_engine(engine,=0A=
>> +								  skcipher_request_cast(req));=0A=
>> +	default:=0A=
>> +		return -EINVAL;=0A=
>> +	}=0A=
>> +}=0A=
> =0A=
> Please don't do this.  As you can see the crypto engine interface=0A=
> wants to you to use the correct type for the request object.  That's=0A=
> what you should do to.=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 engine.=
=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=
=0A=
> In fact I don't understand why you're only using the crypto engine=0A=
> for the backlog case.  Wouldn't it be much simpler if you used the=0A=
> engine unconditionally?=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=
Thanks,=0A=
Iulia=0A=