Re: [RFC PATCH] crypto: RSA padding transform

[Tadeusz Struk <tadeusz.struk@intel.com>]

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;