[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5f28b9a4704a1_62272b02d7c945b4be@john-XPS-13-9370.notmuch>
Date: Mon, 03 Aug 2020 18:28:04 -0700
From: John Fastabend <john.fastabend@...il.com>
To: Martin KaFai Lau <kafai@...com>, bpf@...r.kernel.org
Cc: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Eric Dumazet <edumazet@...gle.com>, kernel-team@...com,
Lawrence Brakmo <brakmo@...com>,
Neal Cardwell <ncardwell@...gle.com>, netdev@...r.kernel.org,
Yuchung Cheng <ycheng@...gle.com>
Subject: RE: [RFC PATCH v4 bpf-next 05/12] bpf: tcp: Add
bpf_skops_established()
Martin KaFai Lau wrote:
> In tcp_init_transfer(), it currently calls the bpf prog to give it a
> chance to handle the just "ESTABLISHED" event (e.g. do setsockopt
> on the newly established sk). Right now, it is done by calling the
> general purpose tcp_call_bpf().
>
> In the later patch, it also needs to pass the just-received skb which
> concludes the 3 way handshake. E.g. the SYNACK received at the active side.
> The bpf prog can then learn some specific header options written by the
> peer's bpf-prog and potentially do setsockopt on the newly established sk.
> Thus, instead of reusing the general purpose tcp_call_bpf(), a new function
> bpf_skops_established() is added to allow passing the "skb" to the bpf prog.
> The actual skb passing from bpf_skops_established() to the bpf prog
> will happen together in a later patch which has the necessary bpf pieces.
>
> A "skb" arg is also added to tcp_init_transfer() such that
> it can then be passed to bpf_skops_established().
>
> Calling the new bpf_skops_established() instead of tcp_call_bpf()
> should be a noop in this patch.
Yep, looks like a noop.
>
> Signed-off-by: Martin KaFai Lau <kafai@...com>
Acked-by: John Fastabend <john.fastabend@...il.com>
[...]
>
> +#ifdef CONFIG_CGROUP_BPF
> +static void bpf_skops_established(struct sock *sk, int bpf_op,
> + struct sk_buff *skb)
Small nit because its an RFC anyways.
Should we call this bpf_skops_fullsock(...) instead? Just a suggestion.
> +{
> + struct bpf_sock_ops_kern sock_ops;
> +
> + sock_owned_by_me(sk);
> +
> + memset(&sock_ops, 0, offsetof(struct bpf_sock_ops_kern, temp));
> + sock_ops.op = bpf_op;
> + sock_ops.is_fullsock = 1;
> + sock_ops.sk = sk;
> + /* skb will be passed to the bpf prog in a later patch. */
> +
> + BPF_CGROUP_RUN_PROG_SOCK_OPS(&sock_ops);
> +}
Powered by blists - more mailing lists