Hi Andrzej, >>> 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. > > Yes, in the case of the padding schemes, using sgl's would actually > save a memcpy both on encrypt/sign and decrypt/verify. Whether it'd > actually help I'm not sure -- the number of pointers you need to > touch, etc. may add up to around 128/256 bytes of memory access > anyway. I think we have akcipher patches using sgl now. Would it make sense to update this patch against them. Regards Marcel -- 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
