Am Mittwoch, 22. Juli 2015, 09:01:15 schrieb Tadeusz Struk:
Hi Tadeusz,
> On 07/21/2015 03:13 PM, Stephan Mueller wrote:
> > +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
> > + * 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
--
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
