Hi Rik: rsnel@xxxxxxxxxxxxxxx wrote: > > It's OK. The source will be more maintainable, but constantly converting > between big and little-endian (on little endian machines) may have a > significant performance impact (I will just test when your gf128 hits > cryptodev-2.6, and complain if it is the case). BTW, the tcrypt speed test for lrw doesn't work for me. > Two more remarks (errors in v2 of my patch): b128ops.h and gf128mul.h > should be in include/ (so they can be used in modules) and the inline > functions in b128ops.h should also be static. Yep they're in include/crypto with all the functions being static inline. > This seems to be the problem, the table is constructed wrongly. > All the calculations take place as if we are on a big endian machine, so > the table entries should never be swapped, so the above line should read > > +#define xx(p, q) 0x##p##q Yes you're quite right. That was the problem. I'll push this into mm as soon as I get the speed tests fixed. Thanks! -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
