From: David Miller <davem@davemloft.net>
To: luto@amacapital.net
Cc: mtk.manpages@gmail.com, willemdebruijn.kernel@gmail.com,
netdev@vger.kernel.org, willemb@google.com,
linux-api@vger.kernel.org
Subject: Re: [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY
Date: Tue, 28 Feb 2017 22:25:28 -0500 (EST) [thread overview]
Message-ID: <20170228.222528.1290209338537176135.davem@davemloft.net> (raw)
In-Reply-To: <CALCETrU3tohXaoOTMi8J4FdTggGhvauHt12KyLFV=Q0FjiDNbg@mail.gmail.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Tue, 28 Feb 2017 11:46:23 -0800
> On Mon, Feb 27, 2017 at 10:57 AM, Michael Kerrisk
> <mtk.manpages@gmail.com> wrote:
>> [CC += linux-api@vger.kernel.org]
>>
>> Hi Willem
>>
>
>>> On a send call with MSG_ZEROCOPY, the kernel pins the user pages and
>>> creates skbuff fragments directly from these pages. On tx completion,
>>> it notifies the socket owner that it is safe to modify memory by
>>> queuing a completion notification onto the socket error queue.
>
> What happens if the user writes to the pages while it's not safe?
Just want to mention that this ability to write to data behind a
network send's back is not a new thing added by MSG_ZEROCOPY.
All of this is already possible with sendfile(). The pages can be
written to completely asynchronously to the data being pulled out of
the page cache into the transmit path.
The crypto case is interesting, but that is a seperate discussion
about an existing problem rather than something specifically new to
the MSG_ZEROCOPY changes.
Thanks.
prev parent reply other threads:[~2017-03-01 3:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170222163901.90834-1-willemdebruijn.kernel@gmail.com>
2017-02-27 18:57 ` [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY Michael Kerrisk
2017-02-28 19:46 ` Andy Lutomirski
2017-02-28 20:43 ` Willem de Bruijn
[not found] ` <CAF=yD-K_0zO3pMeXf-UKGTsD4sNOdyN9KJkUb5MnCO_J5pisrA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-02-28 21:06 ` Andy Lutomirski
2017-03-01 3:28 ` David Miller
2017-03-01 3:43 ` Eric Dumazet
2017-03-02 19:26 ` Andy Lutomirski
2017-02-28 21:09 ` Andy Lutomirski
2017-02-28 21:28 ` Willem de Bruijn
2017-02-28 21:47 ` Eric Dumazet
[not found] ` <1488318476.9415.270.camel-XN9IlZ5yJG9HTL0Zs8A6p+yfmBU6pStAUsxypvmhUTTZJqsBc5GL+g@public.gmane.org>
2017-02-28 22:25 ` Andy Lutomirski
[not found] ` <CALCETrVQj1AEsLEGGkWW1zApGz6_x2rDmE0wz4ft+O5h07f_Ug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-02-28 22:40 ` Eric Dumazet
2017-02-28 22:52 ` Andy Lutomirski
2017-02-28 23:22 ` Eric Dumazet
[not found] ` <1488324131.9415.278.camel-XN9IlZ5yJG9HTL0Zs8A6p+yfmBU6pStAUsxypvmhUTTZJqsBc5GL+g@public.gmane.org>
2017-03-01 0:28 ` Tom Herbert
[not found] ` <CALx6S357ssnbEu7CMrczEjiX25QYBJh3WG=w8KuAoxGQS4aKLA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-03-01 0:37 ` Eric Dumazet
2017-03-01 0:58 ` Willem de Bruijn
2017-03-01 1:50 ` Tom Herbert
2017-03-01 3:25 ` David Miller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170228.222528.1290209338537176135.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=linux-api@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mtk.manpages@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).