[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20201211100944.GA1133@gondor.apana.org.au>
Date: Fri, 11 Dec 2020 21:09:45 +1100
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Horia Geantă <horia.geanta@....com>
Cc: "Iuliana Prodan (OSS)" <iuliana.prodan@....nxp.com>,
Ard Biesheuvel <ardb@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Aymen Sghaier <aymen.sghaier@....com>,
Silvano Di Ninno <silvano.dininno@....com>,
Franck Lenormand <franck.lenormand@....com>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
dl-linux-imx <linux-imx@....com>,
Iuliana Prodan <iuliana.prodan@....com>
Subject: Re: [PATCH 0/5] crypto: caam - avoid allocating memory at crypto
request runtime
On Thu, Dec 10, 2020 at 10:28:35AM +0200, Horia Geantă wrote:
>
> Moving the memory allocations from caam driver into the generic crypto API
> has the side effect of dropping the GFP_DMA allocation flag.
>
> For cases when caam device is limited to 32-bit address space and
> there's no IOMMU, this could lead to DMA API using bounce buffering.
>
> We need to measure the performance impact of this change before deciding
> what we should do next.
This only applies to the control data, right? The actual data
being operated on surely is the most important factor.
In any case, did you respond to Ard's concern about potentially
exhausting DMA memory?
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists