Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp2927491ybn; Thu, 26 Sep 2019 21:02:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqyasETf94rkwRs8BYAjRv8gjAps9A8HW5/aXFOQiOiy1QnkQ4CW/OmZh5uBL7757V1G7/Lx X-Received: by 2002:a17:906:b74e:: with SMTP id fx14mr6161843ejb.226.1569556943457; Thu, 26 Sep 2019 21:02:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569556943; cv=none; d=google.com; s=arc-20160816; b=Llh2CmH84pZ5TUSa0ps9aRFtOgog66y+OFyAj9+nOpJ6SGZDAAj1uQ109ISgV0M8s1 Gsx1FwfQ5OqKYrp9+iC3vxH+VfBoDcDMvr5oncfYAlcrC4DwjHquI9pLSnP5hNm0KMHi N1vQWFR38W9/uDV4+7bo/JPnk/16AK6QISR9Zu8shA4C51+LK77LBTO+Z9OkVRitQ3Cy 0e//QlU1qLWgP42Qf/HgYFyEnawM541xhx6RLjD3sxEBEllXhbEN0JPppVbI6jan7vU1 Rnzn5DeaQfjjZYOp33K8TDKJTsF80VUXuMV17uiKArF/9RFoxaX6tBDa6R8KKgD/Kt0J Rnyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=cxW4omJt1UJVCIdh93XNWqAoArQIc0l7BCLOXC2AgII=; b=O+j2375M5L86+hP4YbCYnqOVVq+574oGbeetbVX9XdNEN7RRe9sjweG/a1It7zM6w8 3cUR9WaBRpFWnm9nEDZNwj3Eq/L+nCiL9q1U/LRSzv+uGK3ZGridmijuzMKX5uc6QqeY z3lijUTYGjpZCmMTcbW25SKjSLpHqUwF8EoezP/+uFZwiAjYe13/q6F9l/+S9hov8GWA 4jTl8Zzi155qEnTpNBUSA0Ye+3sdp6mpeNlGSUu/FNrJOfdRwKsj/UTRGOl2aHKCVloh 3hzruqJ1Jj+FOp1mZEEDqlKncuOhOw50M3W1lNQ5Q1zje5WeBjcreescZKVpVk3STdsW mZag== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i55si760551eda.88.2019.09.26.21.01.56; Thu, 26 Sep 2019 21:02:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725800AbfI0EB4 (ORCPT + 99 others); Fri, 27 Sep 2019 00:01:56 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:39168 "EHLO fornost.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725769AbfI0EB4 (ORCPT ); Fri, 27 Sep 2019 00:01:56 -0400 Received: from gwarestrin.arnor.me.apana.org.au ([192.168.0.7]) by fornost.hmeau.com with smtp (Exim 4.89 #2 (Debian)) id 1iDhRw-0001yA-0u; Fri, 27 Sep 2019 14:01:45 +1000 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Fri, 27 Sep 2019 14:01:41 +1000 Date: Fri, 27 Sep 2019 14:01:41 +1000 From: Herbert Xu To: Linus Torvalds Cc: Pascal Van Leeuwen , Ard Biesheuvel , Linux Crypto Mailing List , Linux ARM , David Miller , Greg KH , "Jason A . Donenfeld" , Samuel Neves , Dan Carpenter , Arnd Bergmann , Eric Biggers , Andy Lutomirski , Will Deacon , Marc Zyngier , Catalin Marinas Subject: Re: [RFC PATCH 18/18] net: wireguard - switch to crypto API for packet encryption Message-ID: <20190927040140.GA24370@gondor.apana.org.au> References: <20190925161255.1871-1-ard.biesheuvel@linaro.org> <20190925161255.1871-19-ard.biesheuvel@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Thu, Sep 26, 2019 at 07:54:03PM -0700, Linus Torvalds wrote: > > There's no "read_potentially_async()" interface that just does the > synchronous read for any cached portion of the data, and then delays > just the IO parts and returns a "here, I gave you X bytes right now, > use this cookie to wait for the rest". Incidentally this is exactly how the crypto async interface works. For example, the same call works whether you're sync or async: aead_request_set_callback(req, ...); aead_request_set_crypt(req, ...); err = crypto_aead_encrypt(req); if (err == -EINPROGRESS) /* * Request is processed asynchronously. * This cannot occur if the algorithm is sync, * e.g., when you specifically allocated sync * algorithms. */ else /* Request was processed synchronously */ We even allow the request to be on the stack in the sync case, e.g., with SYNC_SKCIPHER_REQUEST_ON_STACK. > Maybe nobody would use it. But it really should be possibly to have > interfaces where a good synchronous implementation is _possible_ > without the extra overhead, while also allowing async implementations. So there is really no async overhead in the crypto API AFAICS if you're always doing sync. What you see as overheads are probably the result of having to support multiple underlying algorithms (not just accelerations which can indeed be handled without indirection at least for CPU-based ones). Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt