Re: [PATCH 1/1] arm64: Accelerate Adler32 using arm64 SVE instructions.

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>,
	Ard Biesheuvel <ardb@kernel.org>,
	l00374334 <liqiang64@huawei.com>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Will Deacon <will@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	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.
Date: Wed, 4 Nov 2020 18:49:05 +0000	[thread overview]
Message-ID: <20201104184905.GB4812@sirena.org.uk> (raw)
In-Reply-To: <20201104181256.GG6882@arm.com>

[-- Attachment #1.1: Type: text/plain, Size: 1876 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel