Re: [PATCH v2 5/5] crypto: talitos: Add software backlog queue handling
From: Kim Phillips <hidden>
Date: 2015-03-04 00:28:53
Also in:
linux-crypto
On Tue, 3 Mar 2015 08:21:37 -0500 Martin Hicks [off-list ref] wrote:
quoted hunk ↗ jump to hunk
@@ -1170,6 +1237,8 @@ static struct talitos_edesc *talitos_edesc_alloc(struct device *dev, edesc->dma_len, DMA_BIDIRECTIONAL); edesc->req.desc = &edesc->desc; + /* A copy of the crypto_async_request to use the crypto_queue backlog */ + memcpy(&edesc->req.base, areq, sizeof(struct crypto_async_request));
this seems backward, or, at least can be done more efficiently IMO: talitos_cra_init should set the tfm's reqsize so the rest of the driver can wholly embed its talitos_edesc (which should also wholly encapsulate its talitos_request (i.e., not via a pointer)) into the crypto API's request handle allocation. This would absorb and eliminate the talitos_edesc kmalloc and frees, the above memcpy, and replace the container_of after the crypto_dequeue_request with an offset_of, right? When scatter-gather buffers are needed, we can assume a slower-path and make them do their own allocations, since their sizes vary depending on each request. Of course, a pointer to those allocations would need to be retained somewhere in the request handle. Only potential problem is getting the crypto API to set the GFP_DMA flag in the allocation request, but presumably a CRYPTO_TFM_REQ_DMA crt_flag can be made to handle that. Kim