lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZuQVa8ARmd4fjAup@gondor.apana.org.au>
Date: Fri, 13 Sep 2024 18:35:23 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Kamlesh Gurudasani <kamlesh@...com>
Cc: Eric Biggers <ebiggers@...nel.org>, kristo@...nel.org, will@...nel.org,
	akpm@...ux-foundation.org, davem@...emloft.net,
	mcoquelin.stm32@...il.com, alexandre.torgue@...s.st.com,
	robh@...nel.org, krzysztof.kozlowski+dt@...aro.org,
	conor+dt@...nel.org, vigneshr@...com, catalin.marinas@....com,
	linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
	linux-stm32@...md-mailman.stormreply.com,
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v3 0/6] Add support for MCRC64 engine to calculate 64-bit
 CRC in Full-CPU mode

On Fri, Sep 06, 2024 at 04:44:44PM +0530, Kamlesh Gurudasani wrote:
>
> Just wanted to confirm, if this is being rejected primarily because
> 1. there is no in-kernel user for crc64-iso3309
> 2. or poor performance benefit of using it from userspace

Essentially we don't want to add every random algorithm to the crypto
API because we may end up having to maintain them long after the users
have disappeared.

For a special-purpose algorithm like this, it's perfectly fine to have
a custom driver to be made so that your user-space app can access the
hardware.

> The context for asking is that we have another superset IP known as MCRC
> (this one is MCRC64), which supports crc8/16/32/64(iso-3309).
> 
> That IP has working DMA and will give good offloading numbers.
> 
> We are planning to send drivers for crc8/16/32 for MCRC
> 1.should I put efforts for crc64-iso3309 as well or
> 2.drop the crc64-iso3309 and send only for remaining
> crc8/16/32(standard algorithms with already in-kernel user).
> 
> All our devices either have MCRC or MCRC64.

Do any existing kernel users benefit sufficiently from these algorithms
being offloaded? If no then there is no need to bother.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ