[PATCH v4 6/8] fsverity: improve performance by using multibuffer hashing

[Herbert Xu]

On Thu, Jun 06, 2024 at 08:58:47AM +0200, Ard Biesheuvel wrote:
>
> IPSec users relying on software crypto and authenc() and caring about
> performance seems like a rather niche use case to me.

It's no more niche than fs/verity and dm-integrity.  In fact,
this could potentially be used for all algorithms.  Just the
reduction in the number of function calls may produce enough
of a benefit (this is something I observed when adding GSO,
even without any actual hardware offload, simply aggregating
packets into larger units produced a visible benefit).

> I'm struggling to follow this debate. Surely, if this functionality
> needs to live in ahash, the shash fallbacks need to implement this
> parallel scheme too, or ahash would end up just feeding the requests
> into shash sequentially, defeating the purpose. It is then up to the
> API client to choose between ahash or shash, just as it can today.

I've never suggested it adding it to shash at all.  In fact
that's my primary problem with this interface.  I think it
should be ahash only.  Just like skcipher and aead.

My reasoning is that this should cater mostly to bulk data, i.e.,
multiple pages (e.g., for IPsec we're talking about 64K chunks,
actually that (the 64K limit) is something that we should really
extend, it's not 2014 anymore).  These typically will be more
easily accessed as a number of distinct pages rather than as a
contiguous mapping.

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