Re: [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY
From: Eric Dumazet <hidden>
Date: 2017-02-28 22:40:43
Also in:
netdev
Possibly related (same subject, not in this thread)
- 2017-03-02 · Re: [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY · Andy Lutomirski <luto@amacapital.net>
- 2017-03-01 · Re: [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY · Eric Dumazet <hidden>
- 2017-03-01 · Re: [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY · David Miller <davem@davemloft.net>
- 2017-03-01 · Re: [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY · David Miller <davem@davemloft.net>
- 2017-03-01 · Re: [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY · Tom Herbert <hidden>
On Tue, 2017-02-28 at 14:25 -0800, Andy Lutomirski wrote:
On Tue, Feb 28, 2017 at 1:47 PM, Eric Dumazet [off-list ref] wrote:quoted
On Tue, 2017-02-28 at 13:09 -0800, Andy Lutomirski wrote:quoted
Does this mean that a user program that does a zerocopy send can cause a retransmitted segment to contain different data than the original segment? If so, is that okay?Same remark applies to sendfile() alreadyTrue.quoted
, or other zero copy modes (vmsplice() + splice() )I hate vmsplice(). I thought I remembered it being essentially disabled at some point due to security problems.
Right, zero copy is hard ;) vmsplice() is not disabled in current kernels, unless I missed something.