Am Mittwoch, 22. Juli 2015, 22:14:30 schrieb Tadeusz Struk: Hi Tadeusz, > On 07/22/2015 06:53 PM, Herbert Xu wrote: > > On Wed, Jul 22, 2015 at 02:58:18PM +0300, Horia Geantă wrote: > >> OTOH, caam has SG support for all PK operations, including rsa-encrypt, > >> rsa-decrypt primitives. > >> We are working at upstreaming - aligning our internal caam-pkc with > >> akcipher. > > > > OK. Then we should tweak our interface to allow SGs. Tadeusz? > > We can add a flag to akcipher_request to say if src/dst are SGs or buffers, > but is this really necessary? > What we have now is two implementations that don't support SGs. > In terms of users we have one in kernel i.e module verifier which doesn't > need SGs and proposed user space interface, which is going to copy data > from/to user because the buffers are so small that it is cheaper to copy > than to use the splice/vmsplice calls. To be honest I don't see any benefit > in adding SG support. Tadeusz, to also support your case, I would again suggest to use another integer akin the alignmask which indicates the requested "block size" of one SG entry. Simiarly to alignmask, the implementation of a cipher now has two code paths: one streamlined path where the caller honored the integer and only has one SG list entry which gives you a linear buffer. If the caller does not honor the flag and uses more than one SGL entry, the implementation then does a memcpy to get a linear buffer. This should allow us to convert the API to SGLs and yet maintain the case where an implementation has linear buffers. To reduce code duplication, maybe we can create a service function that converts an SGL into a linear buffer. -- 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
