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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 58BBAC54EE9 for ; Tue, 27 Sep 2022 04:27:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZKm8Bw+wgNX8lwe6pcqSqR1+vAWMqq1GK5hymzf8eUA=; b=TtuVZRe1F5u/aP i56/dfF14F3MapSr/uNsFjhQJRObZA3wGiIEZuZCjJq2XBLbB1EuyK0uuTX2Xh+uw5c7Yzw+XcJdF GIXQEH3pjaKMzA/dYnIpUkVAp5XPlAaz3p3f4nSJ+hjA/oJC0EK0bu3OiZAGL00HCwn3arLungZ75 9APsfZXx3Y7k5qaryJOhgYF4JX7eeToW0YIsgbbqSlsr97Og/xBWw6/voMVZnT0WHNTmvlUK0rtA0 2SWm5JBUKrZ/QJ4fEDo9bfx2hbS4kH+oKFpWHe2yP9zPbpT9pLvI8TaaQG/JO89vq5uqVIWtjtWgl cn0qaL9PK4WyB+WPwbEA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1od2B7-008FDP-BK; Tue, 27 Sep 2022 04:26:41 +0000 Received: from out30-45.freemail.mail.aliyun.com ([115.124.30.45]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1od2B3-008FBx-Da for linux-arm-kernel@lists.infradead.org; Tue, 27 Sep 2022 04:26:39 +0000 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R441e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046059;MF=tianjia.zhang@linux.alibaba.com;NM=1;PH=DS;RN=14;SR=0;TI=SMTPD_---0VQq1IO4_1664252789; Received: from 30.240.100.75(mailfrom:tianjia.zhang@linux.alibaba.com fp:SMTPD_---0VQq1IO4_1664252789) by smtp.aliyun-inc.com; Tue, 27 Sep 2022 12:26:31 +0800 Message-ID: Date: Tue, 27 Sep 2022 12:26:29 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH 16/16] crypto: arm64/sm4 - add ARMv9 SVE cryptography acceleration implementation Content-Language: en-US To: Ard Biesheuvel , Mark Brown Cc: Herbert Xu , "David S. Miller" , Jussi Kivilinna , Catalin Marinas , Will Deacon , Maxime Coquelin , Alexandre Torgue , Eric Biggers , linux-crypto@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com References: <20220926093620.99898-1-tianjia.zhang@linux.alibaba.com> <20220926093620.99898-17-tianjia.zhang@linux.alibaba.com> From: Tianjia Zhang In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220926_212637_683929_F493ECAC X-CRM114-Status: GOOD ( 24.02 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Ard, On 9/26/22 6:02 PM, Ard Biesheuvel wrote: > (cc Mark Brown) > > Hello Tianjia, > > On Mon, 26 Sept 2022 at 11:37, Tianjia Zhang > wrote: >> >> Scalable Vector Extension (SVE) is the next-generation SIMD extension for >> arm64. SVE allows flexible vector length implementations with a range of >> possible values in CPU implementations. The vector length can vary from a >> minimum of 128 bits up to a maximum of 2048 bits, at 128-bit increments. >> The SVE design guarantees that the same application can run on different >> implementations that support SVE, without the need to recompile the code. >> >> SVE was originally introduced by ARMv8, and ARMv9 introduced SVE2 to >> expand and improve it. Similar to the Crypto Extension supported by the >> NEON instruction set for the algorithm, SVE also supports the similar >> instructions, called cryptography acceleration instructions, but this is >> also optional instruction set. >> >> This patch uses SM4 cryptography acceleration instructions and SVE2 >> instructions to optimize the SM4 algorithm for ECB/CBC/CFB/CTR modes. >> Since the encryption of CBC/CFB cannot be parallelized, the Crypto >> Extension instruction is used. >> > > Given that we currently do not support the use of SVE in kernel mode, > this patch cannot be accepted at this time (but the rest of the series > looks reasonable to me, although I have only skimmed over the patches) > > In view of the disappointing benchmark results below, I don't think > this is worth the hassle at the moment. If we can find a case where > using SVE in kernel mode truly makes a [favorable] difference, we can > revisit this, but not without a thorough analysis of the impact it > will have to support SVE in the kernel. Also, the fact that SVE may > also cover cryptographic extensions does not necessarily imply that a > micro-architecture will perform those crypto transformations in > parallel and so the performance may be the same even if VL > 128. > > In summary, please drop this patch for now, and once there are more > encouraging performance numbers, please resubmit it as part of a > series that explicitly enables SVE in kernel mode on arm64, and > documents the requirements and constraints. > > I have cc'ed Mark who has been working on the SVE support., who might > have something to add here as well. > > Thanks, > Ard. > > Thanks for your reply, the current performance of SVE is really unsatisfactory. One reason is that the optimization of SVE needs to deal with more and more complex data shifting operations, such as in CBC/CFB mode, but also in CTR mode. needing more instruction to complete the 128-bit count increment, and the use of CE optimization does not have these complications. In addition, I naively thought that when the VL is 256-bit, the performance will simply double compared to 128-bit. At present, this is not the case. Maybe it is worth using SVE until there are significantly improved performance data. I'll follow your advice and drop this patch. Best regards, Tianjia _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel