public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: davejwatson@fb.com, davem@davemloft.net, daniel@iogearbox.net,
	ast@kernel.org
Cc: netdev@vger.kernel.org
Subject: [bpf-next PATCH v3 06/18] bpf: sockmap, add bpf_msg_apply_bytes() helper
Date: Sun, 18 Mar 2018 12:57:15 -0700	[thread overview]
Message-ID: <20180318195715.14466.28900.stgit@john-Precision-Tower-5810> (raw)
In-Reply-To: <20180318195501.14466.25366.stgit@john-Precision-Tower-5810>

A single sendmsg or sendfile system call can contain multiple logical
messages that a BPF program may want to read and apply a verdict. But,
without an apply_bytes helper any verdict on the data applies to all
bytes in the sendmsg/sendfile. Alternatively, a BPF program may only
care to read the first N bytes of a msg. If the payload is large say
MB or even GB setting up and calling the BPF program repeatedly for
all bytes, even though the verdict is already known, creates
unnecessary overhead.

To allow BPF programs to control how many bytes a given verdict
applies to we implement a bpf_msg_apply_bytes() helper. When called
from within a BPF program this sets a counter, internal to the
BPF infrastructure, that applies the last verdict to the next N
bytes. If the N is smaller than the current data being processed
from a sendmsg/sendfile call, the first N bytes will be sent and
the BPF program will be re-run with start_data pointing to the N+1
byte. If N is larger than the current data being processed the
BPF verdict will be applied to multiple sendmsg/sendfile calls
until N bytes are consumed.

Note1 if a socket closes with apply_bytes counter non-zero this
is not a problem because data is not being buffered for N bytes
and is sent as its received.

Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
 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 ef52953..a557a2a 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -791,7 +791,8 @@ struct bpf_stack_build_id {
 	FN(getsockopt),			\
 	FN(override_return),		\
 	FN(sock_ops_cb_flags_set),	\
-	FN(msg_redirect_map),
+	FN(msg_redirect_map),		\
+	FN(msg_apply_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 2b6c475..17d6775 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -1928,6 +1928,20 @@ struct sock *do_msg_redirect_map(struct sk_msg_buff *msg)
 	.arg4_type      = ARG_ANYTHING,
 };
 
+BPF_CALL_2(bpf_msg_apply_bytes, struct sk_msg_buff *, msg, u32, bytes)
+{
+	msg->apply_bytes = bytes;
+	return 0;
+}
+
+static const struct bpf_func_proto bpf_msg_apply_bytes_proto = {
+	.func           = bpf_msg_apply_bytes,
+	.gpl_only       = false,
+	.ret_type       = RET_INTEGER,
+	.arg1_type	= ARG_PTR_TO_CTX,
+	.arg2_type      = ARG_ANYTHING,
+};
+
 BPF_CALL_1(bpf_get_cgroup_classid, const struct sk_buff *, skb)
 {
 	return task_get_classid(skb);
@@ -3634,6 +3648,8 @@ static const struct bpf_func_proto *sk_msg_func_proto(enum bpf_func_id func_id)
 	switch (func_id) {
 	case BPF_FUNC_msg_redirect_map:
 		return &bpf_msg_redirect_map_proto;
+	case BPF_FUNC_msg_apply_bytes:
+		return &bpf_msg_apply_bytes_proto;
 	default:
 		return bpf_base_func_proto(func_id);
 	}

  parent reply	other threads:[~2018-03-18 19:57 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-18 19:56 [bpf-next PATCH v3 00/18] bpf,sockmap: sendmsg/sendfile ULP John Fastabend
2018-03-18 19:56 ` [bpf-next PATCH v3 01/18] sock: make static tls function alloc_sg generic sock helper John Fastabend
2018-03-18 19:56 ` [bpf-next PATCH v3 02/18] sockmap: convert refcnt to an atomic refcnt John Fastabend
2018-03-18 19:57 ` [bpf-next PATCH v3 03/18] net: do_tcp_sendpages flag to avoid SKBTX_SHARED_FRAG John Fastabend
2018-03-18 19:57 ` [bpf-next PATCH v3 04/18] net: generalize sk_alloc_sg to work with scatterlist rings John Fastabend
2018-03-18 19:57 ` [bpf-next PATCH v3 05/18] bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data John Fastabend
2018-03-18 20:30   ` David Miller
2018-03-19 16:27   ` Alexei Starovoitov
2018-03-18 19:57 ` John Fastabend [this message]
2018-03-18 20:30   ` [bpf-next PATCH v3 06/18] bpf: sockmap, add bpf_msg_apply_bytes() helper David Miller
2018-03-19 16:27   ` Alexei Starovoitov
2018-03-18 19:57 ` [bpf-next PATCH v3 07/18] bpf: sockmap, add msg_cork_bytes() helper John Fastabend
2018-03-18 20:30   ` David Miller
2018-03-19 16:30   ` Alexei Starovoitov
2018-03-19 20:00     ` John Fastabend
2018-03-18 19:57 ` [bpf-next PATCH v3 08/18] bpf: sk_msg program helper bpf_sk_msg_pull_data John Fastabend
2018-03-18 20:31   ` David Miller
2018-03-19 20:24   ` Alexei Starovoitov
2018-03-20  5:54     ` John Fastabend
2018-03-18 19:57 ` [bpf-next PATCH v3 09/18] bpf: add map tests for BPF_PROG_TYPE_SK_MSG John Fastabend
2018-03-18 19:57 ` [bpf-next PATCH v3 10/18] bpf: add verifier " John Fastabend
2018-03-18 19:57 ` [bpf-next PATCH v3 11/18] bpf: sockmap sample, add option to attach SK_MSG program John Fastabend
2018-03-18 19:57 ` [bpf-next PATCH v3 12/18] bpf: sockmap sample, add sendfile test John Fastabend
2018-03-18 19:57 ` [bpf-next PATCH v3 13/18] bpf: sockmap sample, add data verification option John Fastabend
2018-03-18 19:57 ` [bpf-next PATCH v3 14/18] bpf: sockmap, add sample option to test apply_bytes helper John Fastabend
2018-03-18 19:58 ` [bpf-next PATCH v3 15/18] bpf: sockmap sample support for bpf_msg_cork_bytes() John Fastabend
2018-03-18 19:58 ` [bpf-next PATCH v3 16/18] bpf: sockmap add SK_DROP tests John Fastabend
2018-03-18 19:58 ` [bpf-next PATCH v3 17/18] bpf: sockmap sample test for bpf_msg_pull_data John Fastabend
2018-03-18 19:58 ` [bpf-next PATCH v3 18/18] bpf: sockmap test script John Fastabend
2018-03-19 20:20 ` [bpf-next PATCH v3 00/18] bpf,sockmap: sendmsg/sendfile ULP Daniel Borkmann

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=20180318195715.14466.28900.stgit@john-Precision-Tower-5810 \
    --to=john.fastabend@gmail.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davejwatson@fb.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    /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