On Wed, Jun 29, 2016 at 8:02 AM, Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Wed, Jun 29, 2016 at 07:59:22AM -0700, Andy Lutomirski wrote: >>> I suspect that, if you compare a synchronous implementation that can >> use virtual addresses to a DMA based implementation that can't, you'll >> find that, for short messages like tcp md5 uses, the synchronous >> implementation would win every time. I'm wondering if shash should >> gain the ability to use scatterlists and, if it doesn't already have >> it, the ability to use synchronous hardware implementations (like >> SHA-NI, for example, although I don't think that's useful for MD5). > > I don't understand, if you add SGs to shash you get ahash. So > why wouldn't you just use ahash?
Two reasons: 1. Code like tcp md5 would be simpler if it could pass a scatterlist to hash the skb but use a virtual address for the header. 2. The actual calling sequence and the amount of indirection is much less for shash, so hashing short buffer is probably *much* faster. ahash is very featureful, but it's also quite heavyweight and it's missing the ability to use virtual addresses directly (for good reason). shash is simpler and probably much faster on short buffers, but the only feature it's missing for most callers (the ones that want synchronous operation) is the ability to use a scatterlist. Given that the crypto code already has the ability to walk a scatterlist, map it, and hash it, it seems like it might be a nice addition to let shash objects invoke that code path if they want (crypto_shash_update_sg?). This would have no overhead for users that don't call it, and I bet it would both speed up and reduce the amount of code in users like tcp md5. --Andy
