[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c6c23bb6-59c6-988a-b99f-e6c6444f9c3d@gmail.com>
Date: Mon, 26 Nov 2018 07:38:02 -0800
From: John Fastabend <john.fastabend@...il.com>
To: Quentin Monnet <quentin.monnet@...ronome.com>
Cc: Daniel Borkmann <daniel@...earbox.net>, ast@...nel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH bpf-next 1/3] bpf: helper to pop data from messages
On 11/26/18 3:16 AM, Quentin Monnet wrote:
> 2018-11-26 02:05 UTC+0100 ~ Daniel Borkmann <daniel@...earbox.net>
>> On 11/23/2018 02:38 AM, John Fastabend wrote:
>>> This adds a BPF SK_MSG program helper so that we can pop data from a
>>> msg. We use this to pop metadata from a previous push data call.
>>>
>>> Signed-off-by: John Fastabend <john.fastabend@...il.com>
>>> ---
>>> include/uapi/linux/bpf.h | 13 +++-
>>> net/core/filter.c | 169 +++++++++++++++++++++++++++++++++++++++++++++++
>>> net/ipv4/tcp_bpf.c | 14 +++-
>>> 3 files changed, 192 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>>> index c1554aa..64681f8 100644
>>> --- a/include/uapi/linux/bpf.h
>>> +++ b/include/uapi/linux/bpf.h
>>> @@ -2268,6 +2268,16 @@ union bpf_attr {
>>> *
>>> * Return
>>> * 0 on success, or a negative error in case of failure.
>>> + *
>>> + * int bpf_msg_pop_data(struct sk_msg_buff *msg, u32 start, u32 pop, u64 flags)
>>> + * Description
>>> + * Will remove 'pop' bytes from a msg starting at byte 'start'.
>>> + * This result in ENOMEM errors under certain situations where
>>> + * a allocation and copy are required due to a full ring buffer.
>>> + * However, the helper will try to avoid doing the allocation
>>> + * if possible. Other errors can occur if input parameters are
>>> + * invalid either do to start byte not being valid part of msg
>>> + * payload and/or pop value being to large.
>>> */
>
> Hi John,
>
> If you respin could you please update the helper documentation to use
> RST syntax for argument and constant names (*pop* instead of 'pop',
> *msg*, *start*, *flags*, **ENOMEM**), and document the return value from
> the helper?
>
Sure no problem.
> Thanks a lot,
> Quentin
>
Powered by blists - more mailing lists