On Thu, 26 Nov 2020 at 17:00, Iuliana Prodan <iuliana.prodan@xxxxxxx> wrote: > > On 11/26/2020 9:09 AM, Ard Biesheuvel wrote: > > On Wed, 25 Nov 2020 at 22:39, Iuliana Prodan <iuliana.prodan@xxxxxxx> wrote: > >> > >> On 11/25/2020 11:16 PM, Ard Biesheuvel wrote: > >>> On Wed, 25 Nov 2020 at 22:14, Iuliana Prodan (OSS) > >>> <iuliana.prodan@xxxxxxxxxxx> wrote: > >>>> > >>>> From: Iuliana Prodan <iuliana.prodan@xxxxxxx> > >>>> > >>>> Add the option to allocate the crypto request object plus any extra space > >>>> needed by the driver into a DMA-able memory. > >>>> > >>>> Add CRYPTO_TFM_REQ_DMA flag to be used by backend implementations to > >>>> indicate to crypto API the need to allocate GFP_DMA memory > >>>> for private contexts of the crypto requests. > >>>> > >>> > >>> These are always directional DMA mappings, right? So why can't we use > >>> bounce buffering here? > >>> > >> The idea was to avoid allocating any memory in crypto drivers. > >> We want to be able to use dm-crypt with CAAM, which needs DMA-able > >> memory and increasing reqsize is not enough. > > > > But what does 'needs DMA-able memory' mean? DMA operations are > > asynchronous by definition, and so the DMA layer should be able to > > allocate bounce buffers when needed. This will cost some performance > > in cases where the hardware cannot address all of memory directly, but > > this is a consequence of the design, and I don't think we should > > burden the generic API with this. > > > Ard, I believe you're right. > > In CAAM, for req->src and req->dst, which comes from crypto request, we > use DMA mappings without knowing if the memory is DMAable or not. > > We should do the same for CAAM's hw descriptors commands and link > tables. That's the extra memory allocated by increasing reqsize. > It depends on whether any such mappings are non-directional. But I would not expect per-request mappings to be modifiable by both the CPU and the device at the same time. > Horia, do you see any limitations, in CAAM, for not using the above > approach? > > > >> It started from here > >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flinux-crypto%2F71b6f739-d4a8-8b26-bf78-ce9acf9a0f99%40nxp.com%2FT%2F%23m39684173a2f0f4b83d8bcbec223e98169273d1e4&data=04%7C01%7Ciuliana.prodan%40nxp.com%7C436d50e009434fd1c52808d891da3c8f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637419713794116972%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=38rJuxFhPWDJXWc2R66Hu%2Fn7vve9u%2BeF0Evp%2BFAhCwQ%3D&reserved=0 > >> > >>>> For IPsec use cases, CRYPTO_TFM_REQ_DMA flag is also checked in > >>>> esp_alloc_tmp() function for IPv4 and IPv6. > >>>> > >>>> This series includes an example of how a driver can use > >>>> CRYPTO_TFM_REQ_DMA flag while setting reqsize to a larger value > >>>> to avoid allocating memory at crypto request runtime. > >>>> The extra size needed by the driver is added to the reqsize field > >>>> that indicates how much memory could be needed per request. > >>>> > >>>> Iuliana Prodan (4): > >>>> crypto: add CRYPTO_TFM_REQ_DMA flag > >>>> net: esp: check CRYPTO_TFM_REQ_DMA flag when allocating crypto request > >>>> crypto: caam - avoid allocating memory at crypto request runtime for > >>>> skcipher > >>>> crypto: caam - avoid allocating memory at crypto request runtime for > >>>> aead > >>>> > >>>> drivers/crypto/caam/caamalg.c | 130 +++++++++++++++++++++++++--------- > >>>> include/crypto/aead.h | 4 ++ > >>>> include/crypto/akcipher.h | 21 ++++++ > >>>> include/crypto/hash.h | 4 ++ > >>>> include/crypto/skcipher.h | 4 ++ > >>>> include/linux/crypto.h | 1 + > >>>> net/ipv4/esp4.c | 7 +- > >>>> net/ipv6/esp6.c | 7 +- > >>>> 8 files changed, 144 insertions(+), 34 deletions(-) > >>>> > >>>> -- > >>>> 2.17.1 > >>>>
