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;
Date:   Wed, 4 Nov 2020 18:49:05 +0000
From:   Mark Brown <broonie@kernel.org>
To:     Dave Martin <Dave.Martin@arm.com>
Cc:     Alexandre Torgue <alexandre.torgue@st.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        "David S. Miller" <davem@davemloft.net>,
        l00374334 <liqiang64@huawei.com>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Maxime Coquelin <mcoquelin.stm32@gmail.com>,
        Will Deacon <will@kernel.org>,
        Ard Biesheuvel <ardb@kernel.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [PATCH 1/1] arm64: Accelerate Adler32 using arm64 SVE
 instructions.
Message-ID: <20201104184905.GB4812@sirena.org.uk>
References: <20201103121506.1533-1-liqiang64@huawei.com>
 <20201103121506.1533-2-liqiang64@huawei.com>
 <CAMj1kXFJRQ59waFwbe2X0v5pGvMv6Yo6DJPLMEzjxDAThC-+gw@mail.gmail.com>
 <20201103180031.GO6882@arm.com>
 <20201104175032.GA15020@sirena.org.uk>
 <20201104181256.GG6882@arm.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="TakKZr9L6Hm6aLOc"
Content-Disposition: inline
In-Reply-To: <20201104181256.GG6882@arm.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk


--TakKZr9L6Hm6aLOc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Nov 04, 2020 at 06:13:06PM +0000, Dave Martin wrote:
> On Wed, Nov 04, 2020 at 05:50:33PM +0000, Mark Brown wrote:

> > I think at a minimum we'd want to handle the vector length explicitly
> > for kernel mode SVE, vector length independent code will work most of
> > the time but at the very least it feels like a landmine waiting to cause
> > trouble.  If nothing else there's probably going to be cases where it
> > makes a difference for performance.  Other than that I'm not currently

...

> The main reasons for constraining the vector length are a) to hide
> mismatches between CPUs in heterogeneous systems, b) to ensure that
> validated software doesn't run with a vector length it wasn't validated
> for, and c) testing.

> For kernel code, it's reasonable to say that all code should be vector-
> length agnostic unless there's a really good reason not to be.  So we
> may not care too much about (b).

> In that case, just setting ZCR_EL1.LEN to max in kernel_sve_begin() (or
> whatever) probably makes sense.

I agree, that's most likely a good default.

> For (c), it might be useful to have a command-line parameter or debugfs
> widget to constrain the vector length for kernel code; perhaps globally
> or perhaps per driver or algo.

I think a global control would be good for testing, it seems simpler and
easier all round.  The per thing tuning seems more useful for cases
where we run into something like a performance reason to use a limited
set of vector lengths but I think we should only add that when we have
at least one user for it, some examples of actual restrictions we want
would probably be helpful for designing the interface.

> Nonetheless, working up a candidate algorithm to help us see whether
> there is a good use case seems like a worthwhile project, so I don't
> want to discourage that too much.

Definitely worth exploring.

--TakKZr9L6Hm6aLOc
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl+i96AACgkQJNaLcl1U
h9BDdwf/Wf3rFlhyHJXhtm3oJ/tp2NIupBTg/F/Exk30EuZkvBoJ+x6jogqI344/
uRvlOaXl8Cw30CDUpoHk2/F9sU/iULuR1GE/A22PV4qu5cLWDEqUwuALauA1OJ6U
6SnIy6SmCIyv3pRVKWiNEAlN/MzvZDFp3xQ5piUl6dBvK9tg1wD0I89hAJxNSWIo
rTboa3g+5r/Fr0yNY8H1QflGlKuflf1YZaPEPluQsIj8ptzJTv6icBnP9joKytep
EagSqjWcP4zCE/1WuL859nDcrlJvc+6yRG4sqDVT1lgKE0uEQKvkf69J3N2m3Zse
Mw/6CqyFCPj5iM6ueSHcaASZGztDPA==
=6u/G
-----END PGP SIGNATURE-----

--TakKZr9L6Hm6aLOc--