From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7991C432C2 for ; Thu, 26 Sep 2019 11:12:16 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8B09E21A4A for ; Thu, 26 Sep 2019 11:12:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="E77gYTVJ"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="SgBxyX4N" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8B09E21A4A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=zx2c4.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=+blrEmwESXrMpyDRExcui8P2TXY3f84ZCJxNdIO4bvw=; b=E77gYTVJn7pAbp AP06TjDY7tepdaPtc82zDv5jqwLr+DNJgqueimrHzaH4EaGBaHyVx9wdwsSv+y9+SyNI7K1yszisL fKLskitwt2NmFy9bJ032RRuwhXU9BL23tk3/u+28htT+4FJaqreC/uU+0XwmiPc+Ua851PVGzxnaE 8VyOVt965zjHyjmyLCA+nXSsJGwqqR+YPVUDXg6CqW/QLvXGm6Yhtc6iRaO6Q0fjLGZPeqrQl4z3U toatfDmkR2zRrF5Y9cGM4wYmuP4CWw6K0LqLPOKmTW9tA0UVhddyIbA53ZQQYWJ86gVcQ0iNd9NnZ yzZK/HBs+f677V1xct9Q==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.2 #3 (Red Hat Linux)) id 1iDRgv-00030m-VQ; Thu, 26 Sep 2019 11:12:09 +0000 Received: from frisell.zx2c4.com ([192.95.5.64]) by bombadil.infradead.org with esmtps (Exim 4.92.2 #3 (Red Hat Linux)) id 1iDRgr-00030R-UO for linux-arm-kernel@lists.infradead.org; Thu, 26 Sep 2019 11:12:07 +0000 Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 7373a0d8 for ; Thu, 26 Sep 2019 10:26:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=zx2c4.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=mail; bh=0KrXBh/Bsqvx7HfMQP+/WOxM5VQ=; b=SgBxyX 4NMpvWxsmvkJGlPcW1N1PFhincDEmLASGMhzti7agl4WVuCxMjSBiAJBeRFMKAWB 3IH22LQ39469zaaVYF53FIPATv7HE6D7Y6ija/Zvrm7cG7q1y8JPEXbTboQS3MJv szjScWeJmb+okPp1OjUE7WWHLtk+CRxgfpnqj2FqwKURrzS3NbNdEFxUJWGodVou V8+Z1WGBfY4rCD6G1fNaPKLvO8MZVzwzpZ1jwYxMA0Icp0/XFX5lKt0t5VBuryin cQmtXGl7ULEMD1xIuT2CNgI6kLPmaYfzZF3rzuYPrbCUW7hXY6hyKxJe/7HyAqkl /r5T3GNVIm77+iFQ== Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 10cfb3a9 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO) for ; Thu, 26 Sep 2019 10:26:11 +0000 (UTC) Received: by mail-ot1-x32a.google.com with SMTP id 41so1582021oti.12 for ; Thu, 26 Sep 2019 04:12:03 -0700 (PDT) X-Gm-Message-State: APjAAAU6WIxHLGOUU9fojRzm+3usH6jvGbCdffS88VJx3jfASlernEgK w7FYMuium1YDmBzjH2nV9iFRLoPYXbJDUuRFXFw= X-Google-Smtp-Source: APXvYqydG2LXHim6dvGxKuF9QbuQYuwfWsygXO1vvnS37Hb0bd207wjixOynX7Ua7HSFpMjDtZo75uIQRCJWV6/vC2A= X-Received: by 2002:a9d:ec2:: with SMTP id 60mr2198189otj.369.1569496022509; Thu, 26 Sep 2019 04:07:02 -0700 (PDT) MIME-Version: 1.0 References: <20190925161255.1871-1-ard.biesheuvel@linaro.org> In-Reply-To: From: "Jason A. Donenfeld" Date: Thu, 26 Sep 2019 13:06:51 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: chapoly acceleration hardware [Was: Re: [RFC PATCH 00/18] crypto: wireguard using the existing crypto API] To: Pascal Van Leeuwen X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190926_041206_132706_E87788A8 X-CRM114-Status: GOOD ( 15.25 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Catalin Marinas , Herbert Xu , Arnd Bergmann , Ard Biesheuvel , Greg KH , Eric Biggers , Dave Taht , Willy Tarreau , Samuel Neves , Will Deacon , Netdev , Linux Crypto Mailing List , Andy Lutomirski , Marc Zyngier , Dan Carpenter , Linus Torvalds , David Miller , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org [CC +willy, toke, dave, netdev] Hi Pascal On Thu, Sep 26, 2019 at 12:19 PM Pascal Van Leeuwen wrote: > Actually, that assumption is factually wrong. I don't know if anything > is *publicly* available, but I can assure you the silicon is running in > labs already. And something will be publicly available early next year > at the latest. Which could nicely coincide with having Wireguard support > in the kernel (which I would also like to see happen BTW) ... > > Not "at some point". It will. Very soon. Maybe not in consumer or server > CPUs, but definitely in the embedded (networking) space. > And it *will* be much faster than the embedded CPU next to it, so it will > be worth using it for something like bulk packet encryption. Super! I was wondering if you could speak a bit more about the interface. My biggest questions surround latency. Will it be synchronous or asynchronous? If the latter, why? What will its latencies be? How deep will its buffers be? The reason I ask is that a lot of crypto acceleration hardware of the past has been fast and having very deep buffers, but at great expense of latency. In the networking context, keeping latency low is pretty important. Already WireGuard is multi-threaded which isn't super great all the time for latency (improvements are a work in progress). If you're involved with the design of the hardware, perhaps this is something you can help ensure winds up working well? For example, AES-NI is straightforward and good, but Intel can do that because they are the CPU. It sounds like your silicon will be adjacent. How do you envision this working in a low latency environment? Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel