Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191007164610.6881-1-ard.biesheuvel@linaro.org>
 <20191007164610.6881-3-ard.biesheuvel@linaro.org> <8021f3ad396dead64fca36cef018c914f9a3a55d.camel@strongswan.org>
In-Reply-To: <8021f3ad396dead64fca36cef018c914f9a3a55d.camel@strongswan.org>
From:   Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Tue, 15 Oct 2019 12:12:43 +0200
Message-ID: <CAKv+Gu8NcgnxJS5TMKhfLF+NYeB+vYWUDzrP87Hck4-FQ0jShQ@mail.gmail.com>
Subject: Re: [PATCH v3 02/29] crypto: x86/chacha - depend on generic chacha
 library instead of crypto driver
To:     Martin Willi <martin@strongswan.org>
Cc:     "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@vger.kernel.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        David Miller <davem@davemloft.net>,
        "Jason A . Donenfeld" <Jason@zx2c4.com>,
        Samuel Neves <sneves@dei.uc.pt>, Arnd Bergmann <arnd@arndb.de>,
        Eric Biggers <ebiggers@google.com>,
        Andy Lutomirski <luto@kernel.org>,
        Rene van Dorst <opensource@vdorst.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Tue, 15 Oct 2019 at 12:00, Martin Willi <martin@strongswan.org> wrote:
>
> Hi Ard,
>
> > Since turning the FPU on and off is cheap these days, simplify the
> > SIMD routine by dropping the per-page yield, which makes for a
> > cleaner switch to the library API as well.
>
> In my measurements that lazy FPU restore works as intended, and I could
> not identify any slowdown by this change.
>

Thanks for confirming.

> > +++ b/arch/x86/crypto/chacha_glue.c
> > @@ -127,32 +127,32 @@ static int chacha_simd_stream_xor [...]
> >
> > +     do_simd = (walk->total > CHACHA_BLOCK_SIZE) && crypto_simd_usable();
>
> Given that most users (including chacha20poly1305) likely involve
> multiple operations under the same (real) FPU save/restore cycle, those
> length checks both in chacha and in poly1305 hardly make sense anymore.
>
> Obviously under tcrypt we get better results when engaging SIMD for any
> length, but also for real users this seems beneficial. But of course we
> may defer that to a later optimization patch.
>

Given that the description already reasons about FPU save/restore
being cheap these days, I think it would be appropriate to just get
rid of it right away. Especially in the chacha20poly1305 case, where
the separate chacha invocation for the poly nonce is guaranteed to
fail this check, we basically end up going back and forth between the
scalar and the SIMD code, which seems rather suboptimal to me.