Re: [v2 PATCH 00/11] Multibuffer hashing take two

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Feb 16, 2025 at 07:09:57PM +0800, Herbert Xu wrote:
> On Sat, Feb 15, 2025 at 07:38:16PM -0800, Eric Biggers wrote:
> > 
> > This new version hasn't fundamentally changed anything.  It's still a much
> > worse, unnecessarily complex and still incomplete implementation compared to my
> > patchset which has been ready to go for nearly a year already.  Please refer to
> > all the previous feedback that I've given.
> 
> FWIW, my interface is a lot simpler than yours to implement, since
> it doesn't deal with the partial buffer non-sense in assembly.  In
> fact that was a big mistake with the original API, the partial data
> handling should've been moved to the API layer a long time ago.

We've already discussed this.  It is part of the multibuffer optimization, as
instruction interleaving is applicable to partial block handling and
finalization too.  It also makes those parts able to use SIMD.  Both of those
improve performance.  But more importantly it eliminates the need for a separate
descriptor for each message.  That results in massive simplifications up the
stack.  The per-algorithm C glue code is much simpler, the API is much simpler
and has fewer edge cases, and with only one descriptor being needed it becomes
feasible to allocate it on the stack.  Overall it's just much more streamlined.

For all these reasons my version ends up with a much smaller diffstat, despite
the assembly code being longer and more optimized.

I see that you didn't even bother to include any tests for all the edge cases in
your API where descriptors and/or scatterlists aren't synced up.  As I've
explained before, these cases would be a huge pain to get right.

But of course, there is no need to go there in the first place.  Cryptographic
APIs should be simple and not include unnecessary edge cases.  It seems you
still have a misconception that your more complex API would make my work useful
for IPsec, but again that is still incorrect, as I've explained many times.  The
latest bogus claims that you've been making, like that GHASH is not
parallelizable, don't exactly inspire confidence either.

- Eric




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux