On 09/06/2015 07:33 AM, Andrzej Zaborowski wrote: > Probably yes, I also read about the decision to use iov buffers, this > will have a bigger effect on code. The more I think about the sgl support the more it looks to me like it wasn't a good idea. It will be copied into a flat buffer somewhere along the way anyway. Like in the example below. I have that conversion already done, and for SW it looks like the data is copied 4 times for a single operation: 1 - from sgl to flat buffer, because MPI doesn't take sgls, (if the src has more ents) 2 - from buff to MPI, then, after operation 3 - export from MPI to a buff and 4 - from buff to sgl (if is the output sg it also fragmented). I can see now that with all these padding schemes there will be more buffer copied on top of this, so I wonder if it still make sense. Herbert? > > + src = kmalloc(ctx->key_size, >>> + (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) ? >>> + GFP_KERNEL : GFP_ATOMIC); >>> + if (!src) >>> + return -ENOMEM; >>> + >>> + /* Reuse output buffer, add padding in the input */ >>> + child_req->src = src; >>> + child_req->src_len = ctx->key_size; >>> + child_req->dst = req->dst; >>> + child_req->dst_len = req->dst_len; -- 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
