Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3570506pxu; Tue, 15 Dec 2020 10:00:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJyA2n94X3BC+ri6Yu/yANec+AiVB4QqWqCoJTi1VPQ6+47FFxOx5kcQuPHHrbv6JGBQ0AIG X-Received: by 2002:a05:6402:3049:: with SMTP id bu9mr30795171edb.127.1608055231272; Tue, 15 Dec 2020 10:00:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608055231; cv=none; d=google.com; s=arc-20160816; b=aBfjp5OYUFJpNpCf4fN5BuZwG29HLr2ZknHovY75TgXQpjh3I7VDrdtexUcJcDcji3 HlmzzQ9dIkzLPAAeh+o244ZzsXwaGh2PXIX3wKEzl4Li5gyYEt/Ia/mx6mkTTLd8OjjW SjeioUMpgk1cOKq/O8z9GiMGXLWkz/NoGX8C3PGxtNWZHI8ZyuKdaQya8c2zminB4jIA mLMlY3CbKlGQNLLxd4hRfXEcm80renGSCtoe6OnIRMJQ9lYEGEiU6pPgm7N8FC0BZcQg yEl8ISvaOyCZCkFETd6Cf94fqlewyEiJHGr0e4+0HCq40Vb66t10nbXd1Lrc1B/TkK+e Smug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:dkim-signature:date; bh=E9WrqiBu+AtT7jfRiPDWzaum3juVH1UMQjrSz8kXMkA=; b=U311B03BOFU6DNjIfRWAXva/djdZnWkjE4gJrpG52o6IMMnDPndq4ErVP4602mT2Qx IE19NhglttWPBujycTWq8m0gkhynE7GDjd+wFGfsrFeeVXwWnAAnQoXR+fCs254hJd/m BPa1UGwspsQYb0SqMtea/RaLxk5hAmXislgwcwlG7QgcQIRkGdolaAWirlva74Y59fYO nxomZsMVSvjBnVKvHE7ORNQ5M8v2BoAvDjc1c+2XUvHil56pNkdm2XzesvMzsoRI1QyB lt+rLl/FdkRIsPNW0OcxPLLlBLTq763RgHgD6l+bBIgOhLQDrEA+twoeSzKYbXlI7BuN ByXg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=RX4u6mQa; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f11si1221748eje.349.2020.12.15.09.59.55; Tue, 15 Dec 2020 10:00:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=RX4u6mQa; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728433AbgLOR5e (ORCPT + 99 others); Tue, 15 Dec 2020 12:57:34 -0500 Received: from mail.kernel.org ([198.145.29.99]:38358 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731417AbgLOR52 (ORCPT ); Tue, 15 Dec 2020 12:57:28 -0500 Date: Tue, 15 Dec 2020 09:56:45 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1608055007; bh=OHlhOyOXULguAwQuzCFCaHRF+5UzuR2DOvXoghvhOiY=; h=From:To:Cc:Subject:References:In-Reply-To:From; b=RX4u6mQadPglJZLzhC1HeYEkdReYfMl14JOnEbwIx26l6/9Ffch9NPPVRxVaWXycP TGZHCHhvTxD4lFWNOcw6uRSYZvxro4g5uMIMbAx6QINqLiKkcVnQeda7LQOce+VgQK pA6jzWodB8zP3qtiKgiIeQJXu4EIgKV7WjC5FOzlmj/vtxaP+0wPg435KGswnVsSjt fCop8IhwXmaFOSiubl+p6RuUaVZQ/YNGWoyhEEWP1xCJG4Zp/7c9TQPswB0ogaP0NX ft//ZpyvnYuBF8LGVqIg2ocy/CybM7TfhidiOzw6+KztMH+IEYyEnrOCjZJvcGzLba 8kenoAh7L87/w== From: Eric Biggers To: Tony W Wang-oc Cc: herbert@gondor.apana.org.au, davem@davemloft.net, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, TimGuo-oc@zhaoxin.com, CooperYan@zhaoxin.com, QiyuanWang@zhaoxin.com, HerryYang@zhaoxin.com, CobeChen@zhaoxin.com, SilviaZhao@zhaoxin.com Subject: Re: [PATCH] crypto: x86/crc32c-intel - Don't match some Zhaoxin CPUs Message-ID: References: <1607686144-2604-1-git-send-email-TonyWWang-oc@zhaoxin.com> <1f8d17bf-c1d9-6496-d2f8-5773633011fb@zhaoxin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Tue, Dec 15, 2020 at 10:15:29AM +0800, Tony W Wang-oc wrote: > > On 15/12/2020 04:41, Eric Biggers wrote: > > On Mon, Dec 14, 2020 at 10:28:19AM +0800, Tony W Wang-oc wrote: > >> On 12/12/2020 01:43, Eric Biggers wrote: > >>> On Fri, Dec 11, 2020 at 07:29:04PM +0800, Tony W Wang-oc wrote: > >>>> The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2. > >>>> On platforms with Zhaoxin CPUs supporting this X86 feature, When > >>>> crc32c-intel and crc32c-generic are both registered, system will > >>>> use crc32c-intel because its .cra_priority is greater than > >>>> crc32c-generic. This case expect to use crc32c-generic driver for > >>>> some Zhaoxin CPUs to get performance gain, So remove these Zhaoxin > >>>> CPUs support from crc32c-intel. > >>>> > >>>> Signed-off-by: Tony W Wang-oc > >>> > >>> Does this mean that the performance of the crc32c instruction on those CPUs is > >>> actually slower than a regular C implementation? That's very weird. > >>> > >> > >> From the lmbench3 Create and Delete file test on those chips, I think yes. > >> > > > > Did you try measuring the performance of the hashing itself, and not some > > higher-level filesystem operations? > > > > Yes. Was testing on these Zhaoxin CPUs, the result is that with the same > input value the generic C implementation takes fewer time than the > crc32c instruction implementation. > And that is really "working as intended"? Why do these CPUs even declare that they support the crc32c instruction, when it is so slow? Are there any other instruction sets (AES-NI, PCLMUL, SSE, SSE2, AVX, etc.) that these CPUs similarly declare support for but they are uselessly slow? - Eric