[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZmhvnBsqKe7AakY-@gondor.apana.org.au>
Date: Tue, 11 Jun 2024 23:39:08 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Ard Biesheuvel <ardb@...nel.org>,
Steffen Klassert <steffen.klassert@...unet.com>,
netdev@...r.kernel.org, linux-crypto@...r.kernel.org,
fsverity@...ts.linux.dev, dm-devel@...ts.linux.dev, x86@...nel.org,
linux-arm-kernel@...ts.infradead.org,
Sami Tolvanen <samitolvanen@...gle.com>,
Bart Van Assche <bvanassche@....org>,
Tim Chen <tim.c.chen@...ux.intel.com>
Subject: Re: [PATCH v4 6/8] fsverity: improve performance by using
multibuffer hashing
On Tue, Jun 11, 2024 at 11:21:43PM +0800, Herbert Xu wrote:
>
> Therefore if we switched to a linked-list API networking could
> give us the buffers with minimal changes.
BTW, this is not just about parallelising hashing. Just as one of
the most significant benefits of GSO does not come from hardware
offload, but rather the amortisation of (network) stack overhead.
IOW you're traversing a very deep stack once instead of 40 times
(this is the factor for 64K vs MTU, if we extend beyond 64K (which
we absolute should do) the benefit would increase as well).
The same should apply to the Crypto API. So even if this was a
purely software solution with no assembly code at all, it may well
improve GCM performance (at least for users able to feed us bulk
data, like networking).
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