From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?SG9yaWEgR2VhbnTEgw==?= Subject: Re: [PATCH v2 5/5] crypto: talitos: Add software backlog queue handling Date: Tue, 17 Mar 2015 19:58:55 +0200 Message-ID: <55086B5F.9080906@freescale.com> References: <1425388897-5434-1-git-send-email-mort@bork.org> <1425388897-5434-6-git-send-email-mort@bork.org> <20150303182332.546523088b5891a776880c0f@freescale.com> <5506AA4B.303@freescale.com> <20150316191935.81f89e0dafebbbe76ffcb0c0@freescale.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: Scott Wood , Martin Hicks , linuxppc-dev@lists.ozlabs.org, linux-crypto@vger.kernel.org To: Kim Phillips , "David S. Miller" Return-path: In-Reply-To: <20150316191935.81f89e0dafebbbe76ffcb0c0@freescale.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" List-Id: linux-crypto.vger.kernel.org T24gMy8xNy8yMDE1IDI6MTkgQU0sIEtpbSBQaGlsbGlwcyB3cm90ZToKPiBPbiBNb24sIDE2IE1h ciAyMDE1IDEyOjAyOjUxICswMjAwCj4gSG9yaWEgR2VhbnTEgyA8aG9yaWEuZ2VhbnRhQGZyZWVz Y2FsZS5jb20+IHdyb3RlOgo+IAo+PiBPbiAzLzQvMjAxNSAyOjIzIEFNLCBLaW0gUGhpbGxpcHMg d3JvdGU6Cj4+PiBPbmx5IHBvdGVudGlhbCBwcm9ibGVtIGlzIGdldHRpbmcgdGhlIGNyeXB0byBB UEkgdG8gc2V0IHRoZSBHRlBfRE1BCj4+PiBmbGFnIGluIHRoZSBhbGxvY2F0aW9uIHJlcXVlc3Qs IGJ1dCBwcmVzdW1hYmx5IGEKPj4+IENSWVBUT19URk1fUkVRX0RNQSBjcnRfZmxhZyBjYW4gYmUg bWFkZSB0byBoYW5kbGUgdGhhdC4KPj4KPj4gU2VlbXMgdGhlcmUgYXJlIHF1aXRlIGEgZmV3IHBs YWNlcyB0aGF0IGRvIG5vdCB1c2UgdGhlCj4+IHthZWFkLGFibGtjaXBoZXJfYWhhc2h9X3JlcXVl c3RfYWxsb2MoKSBBUEkgdG8gYWxsb2NhdGUgY3J5cHRvIHJlcXVlc3RzLgo+PiBBbW9uZyB0aGVt LCBJUHNlYyBhbmQgZG0tY3J5cHQuCj4+IEkndmUgbG9va2VkIGF0IHRoZSBjb2RlIGFuZCBJIGRv bid0IHRoaW5rIGl0IGNhbiBiZSBjb252ZXJ0ZWQgdG8gdXNlCj4+IGNyeXB0byBBUEkuCj4gCj4g d2h5IG5vdD8KCkl0IHdvdWxkIGltcGx5IGhhdmluZyAyIG1lbW9yeSBhbGxvY2F0aW9ucywgb25l IGZvciBjcnlwdG8gcmVxdWVzdCBhbmQKdGhlIG90aGVyIGZvciB0aGUgcmVzdCBvZiB0aGUgZGF0 YSBidW5kbGVkIHdpdGggdGhlIHJlcXVlc3QgKGZvciBJUHNlYwp0aGF0IHdvdWxkIGJlIEVTTiAr IHNwYWNlIGZvciBJViArIHNnIGVudHJpZXMgZm9yIGF1dGhlbnRpY2F0ZWQtb25seQpkYXRhIGFu ZCBza19idWZmIGV4dGVuc2lvbiwgaWYgbmVlZGVkKS4KClRyeWluZyB0byBoYXZlIGEgc2luZ2xl IGFsbG9jYXRpb24gYnkgbWFraW5nIEVTTiwgSVYgZXRjLiBwYXJ0IG9mIHRoZQpyZXF1ZXN0IHBy aXZhdGUgY29udGV4dCByZXF1aXJlcyBtb2RpZnlpbmcgdGZtLnJlcXNpemUgb24gdGhlIGZseS4K VGhpcyB3b24ndCB3b3JrIHdpdGhvdXQgYWRkaW5nIHNvbWUga2luZCBvZiBsb2NraW5nIGZvciB0 aGUgdGZtLgoKPiAKPj4gVGhpcyBtZWFucyB0aGF0IHRoZSBDUllQVE9fVEZNX1JFUV9ETUEgd291 bGQgYmUgdmlzaWJsZSB0byBhbGwgb2YgdGhlc2UKPj4gcGxhY2VzLiBTb21lIG9mIHRoZSBtYWlu dGFpbmVycyBkbyBub3QgYWdyZWUsIGFzIHlvdSd2ZSBzZWVuLgo+IAo+IHdvdWxkIG1vZGlmeWlu ZyB0aGUgY3J5cHRvIEFQSSB0byBlaXRoZXIgaGF2ZSBhIGRpZmZlcmVudAo+ICpfcmVxdWVzdF9h bGxvYygpIEFQSSwgYW5kL29yIGFkZGluZyBjYWxscyB0byBuZWdvdGlhdGUgdGhlIEdGUCBtYXNr Cj4gYmV0d2VlbiBjcnlwdG8gdXNlcnMgYW5kIGRyaXZlcnMsIGUuZy4sIGdldC9zZXRfZ2ZwX21h c2ssIHdvcms/CgpJIHRoaW5rIHdoYXQgRGF2ZU0gYXNrZWQgZm9yIHdhcyB0aGUgY2hhbmdlIHRv IGJlIHRyYW5zcGFyZW50LgoKQmVzaWRlcyBjb252ZXJ0aW5nIHRvICpfcmVxdWVzdF9hbGxvYygp LCBzZWVtcyB0aGF0IGFsbCBvdGhlciBvcHRpb25zCnJlcXVpcmUgc29tZSBleHRyYSBhd2FyZW5l c3MgZnJvbSB0aGUgdXNlci4KQ291bGQgeW91IGVsYWJvcmF0ZSBvbiB0aGUgaWRlYSBhYm92ZT8K Cj4gCj4+IEFuIGFsdGVybmF0aXZlIHdvdWxkIGJlIGZvciB0YWxpdG9zIHRvIHVzZSB0aGUgcGFn ZSBhbGxvY2F0b3IgdG8gZ2V0IDEgLwo+PiAyIHBhZ2VzIGF0IHByb2JlIHRpbWUgKDQgY2hhbm5l bHMgeCAzMiBlbnRyaWVzL2NoYW5uZWwgeCA2NEIvZGVzY3JpcHRvcgo+PiA9IDgga0IpLCBkbWFf bWFwX3BhZ2UgdGhlIGFyZWEgYW5kIG1hbmFnZSBpdCBpbnRlcm5hbGx5IGZvciB0YWxpdG9zX2Rl c2MKPj4gaHcgZGVzY3JpcHRvcnMuCj4+IFdoYXQgZG8geW91IHRoaW5rPwo+IAo+IFRoZXJlJ3Mg YSBjb21tZW50IGluIGVzcF9hbGxvY190bXAoKTogIlVzZSBzcGFyZSBzcGFjZSBpbiBza2IgZm9y Cj4gdGhpcyB3aGVyZSBwb3NzaWJsZSwiIHdoaWNoIGlzIGlkZWFsbHkgd2hlcmUgd2UnZCB3YW50 IHRvIGJlIChlc3AuCgpPaywgSSdsbCBjaGVjayB0aGF0LiBCdXQgbm90ZSB0aGUgIndoZXJlIHBv c3NpYmxlIiAtIGZpbmRpbmcgcm9vbSBpbiB0aGUKc2tiIHRvIGF2b2lkIHRoZSBhbGxvY2F0aW9u IHdvbid0IGFsd2F5cyBiZSB0aGUgY2FzZSwgYW5kIHRoZW4gd2UncmUKYmFjayB0byBzcXVhcmUg b25lLgoKPiBiZWNhdXNlIHRoYXQgbWVtb3J5IGNvdWxkIGFscmVhZHkgYmUgRE1BLWFibGUpLiAg WW91ciBhYm92ZQo+IHN1Z2dlc3Rpb24gd291bGQgYmUgaW4gdGhlIG9wcG9zaXRlIGRpcmVjdGlv biBvZiB0aGF0LgoKVGhlIHByb3Bvc2FsOgotcmVtb3ZlcyBkbWEgKHVuKW1hcHBpbmcgb24gdGhl IGZhc3QgcGF0aAotYXZvaWRzIHJlcXVlc3RpbmcgZG1hIG1hcHBhYmxlIG1lbW9yeSBmb3IgbW9y ZSB0aGFuIGl0J3MgYWN0dWFsbHkKbmVlZGVkIChDUllQVE9fVEZNX1JFUV9ETUEgZm9yY2VzIGVu dGlyZSByZXF1ZXN0IHRvIGJlIG1hcHBhYmxlLCBub3QKb25seSBpdHMgcHJpdmF0ZSBjb250ZXh0 KQotZm9yIGNhYW0gaXQgaGFzIHRoZSBhZGRlZCBiZW5lZml0IG9mIHNwZWVkaW5nIHRoZSBiZWxv dyBzZWFyY2ggZm9yIHRoZQpvZmZlbmRpbmcgZGVzY3JpcHRvciBpbiB0aGUgU1cgcmluZyBmcm9t IE8obikgdG8gTygxKToKZm9yIChpID0gMDsgQ0lSQ19DTlQoaGVhZCwgdGFpbCArIGksIEpPQlJf REVQVEgpID49IDE7IGkrKykgewoJc3dfaWR4ID0gKHRhaWwgKyBpKSAmIChKT0JSX0RFUFRIIC0g MSk7CgoJaWYgKGpycC0+b3V0cmluZ1tod19pZHhdLmRlc2MgPT0KCSAgICBqcnAtPmVudGluZm9b c3dfaWR4XS5kZXNjX2FkZHJfZG1hKQoJCWJyZWFrOyAvKiBmb3VuZCAqLwp9Cihkcml2ZXJzL2Ny eXB0by9jYWFtL2pyLmMgLSBjYWFtX2RlcXVldWUpCgpIb3JpYQoKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkxpbnV4cHBjLWRldiBtYWlsaW5nIGxpc3QK TGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmcKaHR0cHM6Ly9saXN0cy5vemxhYnMub3JnL2xp c3RpbmZvL2xpbnV4cHBjLWRldg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bn0101.outbound.protection.outlook.com [157.56.110.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 0964E1A09A6 for ; Wed, 18 Mar 2015 04:59:18 +1100 (AEDT) Message-ID: <55086B5F.9080906@freescale.com> Date: Tue, 17 Mar 2015 19:58:55 +0200 From: =?UTF-8?B?SG9yaWEgR2VhbnTEgw==?= MIME-Version: 1.0 To: Kim Phillips , "David S. Miller" Subject: Re: [PATCH v2 5/5] crypto: talitos: Add software backlog queue handling References: <1425388897-5434-1-git-send-email-mort@bork.org> <1425388897-5434-6-git-send-email-mort@bork.org> <20150303182332.546523088b5891a776880c0f@freescale.com> <5506AA4B.303@freescale.com> <20150316191935.81f89e0dafebbbe76ffcb0c0@freescale.com> In-Reply-To: <20150316191935.81f89e0dafebbbe76ffcb0c0@freescale.com> Content-Type: text/plain; charset="utf-8" Cc: Scott Wood , Martin Hicks , linuxppc-dev@lists.ozlabs.org, linux-crypto@vger.kernel.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 3/17/2015 2:19 AM, Kim Phillips wrote: > On Mon, 16 Mar 2015 12:02:51 +0200 > Horia Geantă wrote: > >> On 3/4/2015 2:23 AM, Kim Phillips wrote: >>> 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. >> >> Seems there are quite a few places that do not use the >> {aead,ablkcipher_ahash}_request_alloc() API to allocate crypto requests. >> Among them, IPsec and dm-crypt. >> I've looked at the code and I don't think it can be converted to use >> crypto API. > > why not? It would imply having 2 memory allocations, one for crypto request and the other for the rest of the data bundled with the request (for IPsec that would be ESN + space for IV + sg entries for authenticated-only data and sk_buff extension, if needed). Trying to have a single allocation by making ESN, IV etc. part of the request private context requires modifying tfm.reqsize on the fly. This won't work without adding some kind of locking for the tfm. > >> This means that the CRYPTO_TFM_REQ_DMA would be visible to all of these >> places. Some of the maintainers do not agree, as you've seen. > > would modifying the crypto API to either have a different > *_request_alloc() API, and/or adding calls to negotiate the GFP mask > between crypto users and drivers, e.g., get/set_gfp_mask, work? I think what DaveM asked for was the change to be transparent. Besides converting to *_request_alloc(), seems that all other options require some extra awareness from the user. Could you elaborate on the idea above? > >> An alternative would be for talitos to use the page allocator to get 1 / >> 2 pages at probe time (4 channels x 32 entries/channel x 64B/descriptor >> = 8 kB), dma_map_page the area and manage it internally for talitos_desc >> hw descriptors. >> What do you think? > > There's a comment in esp_alloc_tmp(): "Use spare space in skb for > this where possible," which is ideally where we'd want to be (esp. Ok, I'll check that. But note the "where possible" - finding room in the skb to avoid the allocation won't always be the case, and then we're back to square one. > because that memory could already be DMA-able). Your above > suggestion would be in the opposite direction of that. The proposal: -removes dma (un)mapping on the fast path -avoids requesting dma mappable memory for more than it's actually needed (CRYPTO_TFM_REQ_DMA forces entire request to be mappable, not only its private context) -for caam it has the added benefit of speeding the below search for the offending descriptor in the SW ring from O(n) to O(1): for (i = 0; CIRC_CNT(head, tail + i, JOBR_DEPTH) >= 1; i++) { sw_idx = (tail + i) & (JOBR_DEPTH - 1); if (jrp->outring[hw_idx].desc == jrp->entinfo[sw_idx].desc_addr_dma) break; /* found */ } (drivers/crypto/caam/jr.c - caam_dequeue) Horia