Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <1608325864-4033-1-git-send-email-megha.dey@intel.com>
 <1608325864-4033-4-git-send-email-megha.dey@intel.com> <CAMj1kXGhGopfg19at5N_9q89-UA4irSgMULyDXg+dKhnbRrCZQ@mail.gmail.com>
 <dfb5f2e0-027d-2b9c-aec7-313ff0275381@intel.com> <83d87dec-dd76-1ddc-1e20-4bf1c7db7918@intel.com>
 <YAJJmzWm3rPcdxMs@gmail.com> <7cdbce42-2d40-95bc-d719-62a1580d6ebf@intel.com>
In-Reply-To: <7cdbce42-2d40-95bc-d719-62a1580d6ebf@intel.com>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Sat, 16 Jan 2021 17:48:45 +0100
Message-ID: <CAMj1kXHVGQhMO83qtkVGBV9ghTDrYv+VRz4+vwp91bVoJFqGiw@mail.gmail.com>
Subject: Re: [RFC V1 3/7] crypto: ghash - Optimized GHASH computations
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     Eric Biggers <ebiggers@kernel.org>,
        "Dey, Megha" <megha.dey@intel.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        "David S. Miller" <davem@davemloft.net>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        ravi.v.shankar@intel.com, tim.c.chen@intel.com,
        andi.kleen@intel.com, wajdi.k.feghali@intel.com,
        greg.b.tucker@intel.com, robert.a.kasten@intel.com,
        rajendrakumar.chinnaiyan@intel.com, tomasz.kantecki@intel.com,
        ryan.d.saffores@intel.com, ilya.albrekht@intel.com,
        kyung.min.park@intel.com, Tony Luck <tony.luck@intel.com>,
        ira.weiny@intel.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, 16 Jan 2021 at 06:13, Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 1/15/21 6:04 PM, Eric Biggers wrote:
> > On Fri, Jan 15, 2021 at 04:20:44PM -0800, Dave Hansen wrote:
> >> On 1/15/21 4:14 PM, Dey, Megha wrote:
> >>> Also, I do not know of any cores that implement PCLMULQDQ and not AES-NI.
> >> That's true, bit it's also possible that a hypervisor could enumerate
> >> support for PCLMULQDQ and not AES-NI.  In general, we've tried to
> >> implement x86 CPU features independently, even if they never show up in
> >> a real CPU independently.
> > We only add optimized implementations of crypto algorithms if they are actually
> > useful, though.  If they would never be used in practice, that's not useful.
>
> Yes, totally agree.  If it's not of practical use, it doesn't get merged.
>
> I just wanted to share what we do for other related but independent CPU
> features.

Thanks for the insight.

The issue with the current GHASH driver is that it uses infrastructure
that we may decide to remove (the async cryptd helper [0]). So adding
more dependencies on that without any proven benefit should obviously
be avoided at this time as well.

[0] https://lore.kernel.org/linux-arm-kernel/20201218170106.23280-1-ardb@kernel.org/