Am Donnerstag, 12. Januar 2017, 23:51:28 CET schrieb Herbert Xu: Hi Herbert, > On Sun, Dec 25, 2016 at 06:15:06PM +0100, Stephan Müller wrote: > > + * The following concept of the memory management is used: > > + * > > + * The kernel maintains two SGLs, the TX SGL and the RX SGL. The TX SGL > > is > > + * filled by user space with the data submitted via sendpage/sendmsg. > > Filling + * up the TX SGL does not cause a crypto operation -- the data > > will only be + * tracked by the kernel. Upon receipt of one recvmsg call, > > the caller must + * provide a buffer which is tracked with the RX SGL. > > + * > > + * During the processing of the recvmsg operation, the cipher request is > > + * allocated and prepared. To support multiple recvmsg operations > > operating + * on one TX SGL, an offset pointer into the TX SGL is > > maintained. The TX SGL + * that is used for the crypto request is > > scatterwalk_ffwd by the offset + * pointer to obtain the start address > > the crypto operation shall use for + * the input data. > > I think this is overcomplicating things. The async interface > should be really simple. It should be exactly the same as the > sync interface, except that completion is out-of-line. > > So there should be no mixing of SGLs from different requests. > Just start with a clean slate after each recvmsg regardless of > whether it's sync or async. > > The only difference in the async case is that you need to keep a > reference to the old pages and free them upon completion. But this > should in no way interfere with subsequent requests. That would mean that we would only support one IOCB. At least with algif_skcipher, having multiple IOCBs would reduce the number of system calls user space needs to make for multiple plaintext / ciphertext blocks. But then, with the use of IOVECs, user space could provide all input data with one system call anyway. Ok, I will update the patch as suggested. > > Cheers, 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
