Am Mittwoch, 22. Juli 2015, 09:01:15 schrieb Tadeusz Struk:

Hi Tadeusz,

On 07/21/2015 03:13 PM, Stephan Mueller wrote:

quoted

+static ssize_t akcipher_sendpage(struct socket *sock, struct page *page,
+				 int offset, size_t size, int flags)
+{
+	struct sock *sk = sock->sk;
+	struct alg_sock *ask = alg_sk(sk);
+	struct akcipher_ctx *ctx = ask->private;
+	int err = -EINVAL;
+
+	if (flags & MSG_SENDPAGE_NOTLAST)
+		flags |= MSG_MORE;
+
+	lock_sock(sk);
+
+	/*
+	 * We do not allow mixing of sendmsg and sendpage calls as this would
+	 * require a hairy memory management.
+	 *
+	 * This check also guards against double call of sendpage.
+	 * We require that the output buffer size must be provided with one
+	 * sendpage request as otherwise we cannot have a linear buffer 

required

quoted

+	 * by the akcipher API.
+	 */
+	if (ctx->req_data_ptr)
+		goto unlock;

Shouldn't we be more flexible and copy the data if it comes in chunks here
too. The user doesn't really have control over this and it would look bad
if splice would randomly fail for a valid buffer.

I concur with you. But we have only two options:

- either use SGLs which the current akcipher API does not do

- or do a memcpy of the sendpage data into the internal buffer

As the sendpage already has a speed penalty, I did not like the latter one. 
Based on my measurements for AEAD, Hash and skicpher, sendpage starts to 
become faster than sendmsg with input buffers > 8 to 16 kBytes (sendpage as at 
least 4 syscalls where sendmsg uses only two).

As our current akcipher API does not reach the mentioned limit, I opted to 
require one sendpage call.

But if we change the akcipher API to SGLs, I will lift that limit.

Thanks


-- 
Ciao
Stephan