Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp266582rwi; Fri, 14 Oct 2022 01:26:41 -0700 (PDT) X-Google-Smtp-Source: AMsMyM74qECizvyzOxAQjOSPGHd90ozbK15CG8Wtj0osCHM7dJlGi2YZKzzVqbpd8LLcfCdIQjXf X-Received: by 2002:a17:906:9b8e:b0:78c:65a4:af84 with SMTP id dd14-20020a1709069b8e00b0078c65a4af84mr2741085ejc.127.1665736001115; Fri, 14 Oct 2022 01:26:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665736001; cv=none; d=google.com; s=arc-20160816; b=UZtkIS6jfd6aOmySwbSqGcQvxCdupfm+tWgLrO8qtn8GE3ihIAQZJt6u3KEtVW9oEB Y6gynfREBN0kgP/NmSvVgWkc3RUmjMv8HwKW+TS0H4OsKJJzC7fxOv9eXbo1m9pfZ75G u6gbGZflACgsyIvU6KO4hqXqjyVcIsQxRVNGjPwlkcZTmwXrM1RTGS7Ze2TJJieYwifq a+SXh21EshictmDg7+lA4WJ/Z3slBpK90SeGGLyEk+MINJuEjXMgvslvZtuUUyHuZbVc icM8xLeZgYSjImK0PoU8HiEwH28nnVVKX+kTSBEnrIYJz19axUdJfMvLTNnJuwB530hT /S5w== 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:date; bh=KtPzfMxoJM8IpGJJGVl/rJYHtLLvf1WdCww7m1Cp0nw=; b=y+KeMSX+LzsvR92O2XEcCmvEBJKN1exvvX177zS8gB4rzYPNFCnKD8d5uJ+vSg66Ki pHzoIyFZbsHRy+3g5VvxwBfWF3PDsHARFdliJB4xzh/qpveYjhCWJeBlSc/jGmyKbrPX 9tx8oq297lfLLIdXEN0j0KgpSYUEc6E+HYMVGAx6L7v9bYJbYTwE00Tzcw9f04nPGlIf NmdzWVqXxWzjlOMROYloH120XpZ3xPpEBSHjUHTYO+Gju0HV78js4kJ7idH3buk3Vhx5 +0a8dFyzE93eI9bQPEbsErxSkbSizyDAGG/Sfa/vnWNyUknJ9VFNcJ3zmyG+5KyDNIe1 Y3VA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t25-20020a1709064f1900b00783d969f337si1481233eju.307.2022.10.14.01.26.13; Fri, 14 Oct 2022 01:26:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229541AbiJNIXT (ORCPT + 99 others); Fri, 14 Oct 2022 04:23:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60402 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229518AbiJNIXS (ORCPT ); Fri, 14 Oct 2022 04:23:18 -0400 Received: from fornost.hmeau.com (helcar.hmeau.com [216.24.177.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5EF5FB1DEE; Fri, 14 Oct 2022 01:23:13 -0700 (PDT) Received: from gwarestrin.arnor.me.apana.org.au ([192.168.103.7]) by fornost.hmeau.com with smtp (Exim 4.94.2 #2 (Debian)) id 1ojFy7-00EdJV-NW; Fri, 14 Oct 2022 19:23:00 +1100 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Fri, 14 Oct 2022 16:22:59 +0800 Date: Fri, 14 Oct 2022 16:22:59 +0800 From: Herbert Xu To: "Elliott, Robert (Servers)" Cc: Eric Biggers , "davem@davemloft.net" , "tim.c.chen@linux.intel.com" , "ap420073@gmail.com" , "ardb@kernel.org" , "linux-crypto@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2 19/19] crypto: x86/sha - register only the best function Message-ID: References: <20221006223151.22159-1-elliott@hpe.com> <20221012215931.3896-1-elliott@hpe.com> <20221012215931.3896-20-elliott@hpe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Thu, Oct 13, 2022 at 10:59:08PM +0000, Elliott, Robert (Servers) wrote: > > I have done some testing with extra patches that do that for > that very reason. Is there much overhead from having a module > loaded and registered in the crypto system, but not being > chosen for use? I don't think it's a big deal. The system is designed to cope with multiple implementations and picking the best option. IOW if the overhead is an issue then that's something we'd need to address in the core API code rather than trying to paper over it by reducing the number of registered algorithms. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt