From: John Fastabend <john.fastabend@gmail.com>
To: Shmulik Ladkani <shmulik@metanetworks.com>,
bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>
Cc: Andrii Nakryiko <andrii@kernel.org>,
Paul Chaignon <paul@isovalent.com>,
Shmulik Ladkani <shmulik.ladkani@gmail.com>
Subject: RE: [PATCH v3 bpf-next 1/3] bpf: Support setting variable-length tunnel options
Date: Tue, 23 Aug 2022 00:59:01 -0700 [thread overview]
Message-ID: <630488c5d0f99_2ad4d720813@john.notmuch> (raw)
In-Reply-To: <20220822052152.378622-2-shmulik.ladkani@gmail.com>
Shmulik Ladkani wrote:
> Existing 'bpf_skb_set_tunnel_opt' allows setting tunnel options given
> an option buffer (ARG_PTR_TO_MEM|MEM_RDONLY) and the compile-time
> fixed buffer size (ARG_CONST_SIZE).
>
> However, in certain cases we wish to set tunnel options of dynamic
> length.
>
> For example, we have an ebpf program that gets geneve options on
> incoming packets, stores them into a map (using a key representing
> the incoming flow), and later needs to assign *same* options to
> reply packets (belonging to same flow).
>
> This is currently imposssibly without knowing sender's exact geneve
> options length, which unfortunately is dymamic.
>
> Introduce 'skb_set_var_tunnel_opt'. This is a variant of
> 'bpf_skb_set_tunnel_opt' which gets an *additional* parameter 'len',
> which is the byte length from 'opt' buffer to copy into ip_tunnnel_info.
>
> The 'size' parameter is kept ARG_CONST_SIZE. This way, verifier can still
> safe-guard buffer access. 'len' must never exceed 'size', o/w EINVAL is
> returned.
>
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
> ---
> v3: Avoid 'inline' for the __bpf_skb_set_tunopt helper function
> ---
> include/uapi/linux/bpf.h | 12 ++++++++++++
> net/core/filter.c | 34 +++++++++++++++++++++++++++++++---
> tools/include/uapi/linux/bpf.h | 12 ++++++++++++
> 3 files changed, 55 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 934a2a8beb87..1b965dfd0c80 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -5355,6 +5355,17 @@ union bpf_attr {
> * Return
> * Current *ktime*.
> *
> + * long bpf_skb_set_var_tunnel_opt(struct sk_buff *skb, void *opt, u32 size, u32 len)
> + * Description
> + * Set tunnel options metadata for the packet associated to *skb*
> + * to the variable length *len* bytes of option data contained in
> + * the raw buffer *opt* sized *size*.
> + *
> + * See also the description of the **bpf_skb_get_tunnel_opt**\ ()
> + * helper for additional information.
> + * Return
> + * 0 on success, or a negative error in case of failure.
This API feels akward to me. Could you collapse this by using a dynamic pointer,
recently added? And drop the ptr_to_mem+const_size part at least? That seems
redundant with latest kernels.
And then is there a case where size != len? Probably I guess? Anyways having
a signature like tunnel_otpion(skb, opt, len) looks a lot like memcpy to me
and feels familiar.
[...]
>
> +static const struct bpf_func_proto bpf_skb_set_var_tunnel_opt_proto = {
> + .func = bpf_skb_set_var_tunnel_opt,
> + .gpl_only = false,
> + .ret_type = RET_INTEGER,
> + .arg1_type = ARG_PTR_TO_CTX,
> + .arg2_type = ARG_PTR_TO_MEM | MEM_RDONLY,
> + .arg3_type = ARG_CONST_SIZE,
> + .arg4_type = ARG_ANYTHING,
> +};
> +
next prev parent reply other threads:[~2022-08-23 7:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-22 5:21 [PATCH v3 bpf-next 0/3] bpf: Support setting variable-length tunnel options Shmulik Ladkani
2022-08-22 5:21 ` [PATCH v3 bpf-next 1/3] " Shmulik Ladkani
2022-08-23 7:59 ` John Fastabend [this message]
2022-08-23 9:47 ` Shmulik Ladkani
2022-08-31 8:34 ` Shmulik Ladkani
2022-08-31 19:07 ` Joanne Koong
2022-08-31 19:40 ` Shmulik Ladkani
2022-09-02 15:51 ` Shmulik Ladkani
2022-08-22 5:21 ` [PATCH v3 bpf-next 2/3] selftests/bpf: Simplify test_tunnel setup for allowing non-local tunnel traffic Shmulik Ladkani
2022-08-22 5:21 ` [PATCH v3 bpf-next 3/3] selftests/bpf: Add geneve with bpf_skb_set_var_tunnel_opt test-case to test_progs Shmulik Ladkani
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=630488c5d0f99_2ad4d720813@john.notmuch \
--to=john.fastabend@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=paul@isovalent.com \
--cc=shmulik.ladkani@gmail.com \
--cc=shmulik@metanetworks.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.