linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Horia Geantă" <horia.geanta@nxp.com>
To: "Iuliana Prodan (OSS)" <iuliana.prodan@oss.nxp.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Ard Biesheuvel <ardb@kernel.org>,
	"David S. Miller" <davem@davemloft.net>
Cc: 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: Thu, 10 Dec 2020 10:28:35 +0200	[thread overview]
Message-ID: <d454a0da-395d-3893-9ae1-f52236bcdde8@nxp.com> (raw)
In-Reply-To: <20201203013524.30495-1-iuliana.prodan@oss.nxp.com>

On 12/3/2020 3:35 AM, Iuliana Prodan (OSS) wrote:
> From: Iuliana Prodan <iuliana.prodan@nxp.com>
> 
> This series removes CRYPTO_ALG_ALLOCATES_MEMORY flag and
> allocates the memory needed by the driver, to fulfil a
> request, within the crypto request object.
> The extra size needed for base extended descriptor, hw
> descriptor commands and link tables is added to the reqsize
> field that indicates how much memory could be needed per request.
> 
> CRYPTO_ALG_ALLOCATES_MEMORY flag is limited only to
> dm-crypt use-cases, which seems to be 4 entries maximum.
> Therefore in reqsize we allocate memory for maximum 4 entries
> for src and 4 for dst, aligned.
> If the driver needs more than the 4 entries maximum, the memory
> is dynamically allocated, at runtime.
> 
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.

Thanks,
Horia

  parent reply	other threads:[~2020-12-10  8:29 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ă [this message]
2020-12-11 10:09   ` Herbert Xu

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=d454a0da-395d-3893-9ae1-f52236bcdde8@nxp.com \
    --to=horia.geanta@nxp.com \
    --cc=ardb@kernel.org \
    --cc=aymen.sghaier@nxp.com \
    --cc=davem@davemloft.net \
    --cc=franck.lenormand@nxp.com \
    --cc=herbert@gondor.apana.org.au \
    --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).