Am Montag, 7. September 2015, 07:31:56 schrieb Tadeusz Struk: Hi Tadeusz, >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? When the padding stuff comes into play, I think the SGL approach avoids memcpy() invocations. For example, Andrzej's approach currently is to copy the *entire* source data into a buffer where the padding is added. With SGLs, Andrzej only needs a buffer with the padding (which I would think could even reside on the stack, provided some bounds checks are done), and modify the SGL by preprending the padding buffer to the SGL with the source data. > >> + 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 Ciao Stephan -- 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
