From: Herbert Xu <herbert@gondor.apana.org.au>
To: "Horia Geantă" <horia.geanta@nxp.com>
Cc: "Iuliana Prodan (OSS)" <iuliana.prodan@oss.nxp.com>,
Ard Biesheuvel <ardb@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Aymen Sghaier <aymen.sghaier@nxp.com>,
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>,
Iuliana Prodan <iuliana.prodan@nxp.com>
Subject: Re: [PATCH 0/5] crypto: caam - avoid allocating memory at crypto request runtime
Date: Fri, 11 Dec 2020 21:09:45 +1100 [thread overview]
Message-ID: <20201211100944.GA1133@gondor.apana.org.au> (raw)
In-Reply-To: <d454a0da-395d-3893-9ae1-f52236bcdde8@nxp.com>
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@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
prev parent reply other threads:[~2020-12-11 10:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-03 1:35 [PATCH 0/5] crypto: caam - avoid allocating memory at crypto request runtime Iuliana Prodan (OSS)
2020-12-03 1:35 ` [PATCH 1/5] crypto: caam/jr - avoid allocating memory at crypto request runtime for skcipher Iuliana Prodan (OSS)
2020-12-03 1:35 ` [PATCH 2/5] crypto: caam/jr - avoid allocating memory at crypto request runtime for aead Iuliana Prodan (OSS)
2020-12-03 1:35 ` [PATCH 3/5] crypto: caam/jr - avoid allocating memory at crypto request runtime fost hash Iuliana Prodan (OSS)
2020-12-03 1:35 ` [PATCH 4/5] crypto: caam/qi - avoid allocating memory at crypto request runtime Iuliana Prodan (OSS)
2020-12-03 1:35 ` [PATCH 5/5] crypto: caam/qi2 " Iuliana Prodan (OSS)
2020-12-03 8:34 ` [PATCH 0/5] crypto: caam " Ard Biesheuvel
2020-12-03 8:38 ` Herbert Xu
2020-12-10 8:28 ` Horia Geantă
2020-12-11 10:09 ` Herbert Xu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201211100944.GA1133@gondor.apana.org.au \
--to=herbert@gondor.apana.org.au \
--cc=ardb@kernel.org \
--cc=aymen.sghaier@nxp.com \
--cc=davem@davemloft.net \
--cc=franck.lenormand@nxp.com \
--cc=horia.geanta@nxp.com \
--cc=iuliana.prodan@nxp.com \
--cc=iuliana.prodan@oss.nxp.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=silvano.dininno@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).