From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f195.google.com ([209.85.192.195]:45652 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030883AbeCSUBP (ORCPT ); Mon, 19 Mar 2018 16:01:15 -0400 Received: by mail-pf0-f195.google.com with SMTP id l27so2942626pfk.12 for ; Mon, 19 Mar 2018 13:01:15 -0700 (PDT) Subject: Re: [bpf-next PATCH v3 07/18] bpf: sockmap, add msg_cork_bytes() helper To: Alexei Starovoitov Cc: davejwatson@fb.com, davem@davemloft.net, daniel@iogearbox.net, ast@kernel.org, netdev@vger.kernel.org References: <20180318195501.14466.25366.stgit@john-Precision-Tower-5810> <20180318195720.14466.35911.stgit@john-Precision-Tower-5810> <20180319163012.imwxwjcp7x6dpi65@ast-mbp.dhcp.thefacebook.com> From: John Fastabend Message-ID: <553b4bce-2dab-7a85-e289-c1d0d9d0f7c6@gmail.com> Date: Mon, 19 Mar 2018 13:00:39 -0700 MIME-Version: 1.0 In-Reply-To: <20180319163012.imwxwjcp7x6dpi65@ast-mbp.dhcp.thefacebook.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org List-ID: On 03/19/2018 09:30 AM, Alexei Starovoitov wrote: > On Sun, Mar 18, 2018 at 12:57:20PM -0700, John Fastabend wrote: >> In the case where we need a specific number of bytes before a >> verdict can be assigned, even if the data spans multiple sendmsg >> or sendfile calls. The BPF program may use msg_cork_bytes(). >> >> The extreme case is a user can call sendmsg repeatedly with >> 1-byte msg segments. Obviously, this is bad for performance but >> is still valid. If the BPF program needs N bytes to validate >> a header it can use msg_cork_bytes to specify N bytes and the >> BPF program will not be called again until N bytes have been >> accumulated. The infrastructure will attempt to coalesce data >> if possible so in many cases (most my use cases at least) the >> data will be in a single scatterlist element with data pointers >> pointing to start/end of the element. However, this is dependent >> on available memory so is not guaranteed. So BPF programs must >> validate data pointer ranges, but this is the case anyways to >> convince the verifier the accesses are valid. >> >> Signed-off-by: John Fastabend >> --- >> include/uapi/linux/bpf.h | 3 ++- >> net/core/filter.c | 16 ++++++++++++++++ >> 2 files changed, 18 insertions(+), 1 deletion(-) >> >> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h >> index a557a2a..1765cfb 100644 >> --- a/include/uapi/linux/bpf.h >> +++ b/include/uapi/linux/bpf.h >> @@ -792,7 +792,8 @@ struct bpf_stack_build_id { >> FN(override_return), \ >> FN(sock_ops_cb_flags_set), \ >> FN(msg_redirect_map), \ >> - FN(msg_apply_bytes), >> + FN(msg_apply_bytes), \ >> + FN(msg_cork_bytes), >> >> /* integer value in 'imm' field of BPF_CALL instruction selects which helper >> * function eBPF program intends to call >> diff --git a/net/core/filter.c b/net/core/filter.c >> index 17d6775..0c9daf6 100644 >> --- a/net/core/filter.c >> +++ b/net/core/filter.c >> @@ -1942,6 +1942,20 @@ struct sock *do_msg_redirect_map(struct sk_msg_buff *msg) >> .arg2_type = ARG_ANYTHING, >> }; >> >> +BPF_CALL_2(bpf_msg_cork_bytes, struct sk_msg_buff *, msg, u32, bytes) >> +{ >> + msg->cork_bytes = bytes; >> + return 0; >> +} > > my understanding that setting it here and in the other helper *_bytes to zero > will be effectively a nop. Right? > Correct, setting cork_bytes or apply_bytes to zero is just a nop. > Acked-by: Alexei Starovoitov >