On 03/07/2018 04:25 AM, John Fastabend wrote:
[...]
> Thought about this a bit more and chatted with Daniel a bit. I think
> a better solution is to set data_start = data_end = 0 by default in the
> sendpage case. This will disallow any read/writes into the sendpage
> data. Then if the user needs t
From: John Fastabend
Date: Tue, 6 Mar 2018 19:25:01 -0800
> What do you think?
Sounds good from your description, I can't wait to see it :-)
On 03/06/2018 10:18 AM, John Fastabend wrote:
> On 03/06/2018 07:47 AM, David Miller wrote:
>> From: John Fastabend
>> Date: Mon, 5 Mar 2018 23:06:01 -0800
>>
>>> On 03/05/2018 10:42 PM, David Miller wrote:
From: John Fastabend
Date: Mon, 5 Mar 2018 22:22:21 -0800
> All I meant
On 03/06/2018 07:47 AM, David Miller wrote:
> From: John Fastabend
> Date: Mon, 5 Mar 2018 23:06:01 -0800
>
>> On 03/05/2018 10:42 PM, David Miller wrote:
>>> From: John Fastabend
>>> Date: Mon, 5 Mar 2018 22:22:21 -0800
>>>
All I meant by this is if an application uses sendfile() call
From: John Fastabend
Date: Mon, 5 Mar 2018 23:06:01 -0800
> On 03/05/2018 10:42 PM, David Miller wrote:
>> From: John Fastabend
>> Date: Mon, 5 Mar 2018 22:22:21 -0800
>>
>>> All I meant by this is if an application uses sendfile() call
>>> there is no good way to know when/if the kernel side w
On 03/05/2018 10:42 PM, David Miller wrote:
> From: John Fastabend
> Date: Mon, 5 Mar 2018 22:22:21 -0800
>
>> All I meant by this is if an application uses sendfile() call
>> there is no good way to know when/if the kernel side will copy or
>> xmit the data. So a reliable user space application
From: John Fastabend
Date: Mon, 5 Mar 2018 22:22:21 -0800
> All I meant by this is if an application uses sendfile() call
> there is no good way to know when/if the kernel side will copy or
> xmit the data. So a reliable user space application will need to
> only modify the data if it "knows" th
On 03/05/2018 09:42 PM, David Miller wrote:
> From: John Fastabend
> Date: Mon, 5 Mar 2018 14:53:08 -0800
>
>> I decided to make the default no-copy to mirror the existing
>> sendpage() semantics and then to add the flag later. The flag
>> support is not in this series simply because I wanted to
From: John Fastabend
Date: Mon, 5 Mar 2018 14:53:08 -0800
> I decided to make the default no-copy to mirror the existing
> sendpage() semantics and then to add the flag later. The flag
> support is not in this series simply because I wanted to get the
> base support in first.
What existing sendp
On 03/05/2018 01:40 PM, David Miller wrote:
> From: John Fastabend
> Date: Mon, 05 Mar 2018 11:51:22 -0800
>
>> BPF_PROG_TYPE_SK_MSG supports only two return codes SK_PASS and
>> SK_DROP. Returning SK_DROP free's the copied data in the sendmsg
>> case and in the sendpage case leaves the data unto
From: John Fastabend
Date: Mon, 05 Mar 2018 11:51:22 -0800
> BPF_PROG_TYPE_SK_MSG supports only two return codes SK_PASS and
> SK_DROP. Returning SK_DROP free's the copied data in the sendmsg
> case and in the sendpage case leaves the data untouched. Both cases
> return -EACESS to the user. Retur
11 matches
Mail list logo