From: Eric Dumazet <eric.dumazet@gmail.com>
To: Lawrence Brakmo <brakmo@fb.com>, netdev <netdev@vger.kernel.org>
Cc: Kernel Team <kernel-team@fb.com>, Blake Matheny <bmatheny@fb.com>,
Alexei Starovoitov <ast@fb.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Neal Cardwell <ncardwell@google.com>,
Yuchung Cheng <ycheng@google.com>
Subject: Re: [PATCH bpf-next v5 05/11] bpf: Adds field bpf_sock_ops_flags to tcp_sock
Date: Tue, 09 Jan 2018 15:30:28 -0800 [thread overview]
Message-ID: <1515540628.131759.15.camel@gmail.com> (raw)
In-Reply-To: <20180109210704.893375-6-brakmo@fb.com>
On Tue, 2018-01-09 at 13:06 -0800, Lawrence Brakmo wrote:
> Adds field bpf_sock_ops_flags to tcp_sock and bpf_sock_ops. Its primary
> use is to determine if there should be calls to sock_ops bpf program at
> various points in the TCP code. The field is initialized to zero,
> disabling the calls. A sock_ops BPF program can set, per connection and
> as necessary, when the connection is established.
>
> It also adds support for reading and writting the field within a
> sock_ops BPF program.
>
> Examples of where to call the bpf program:
>
> 1) When RTO fires
> 2) When a packet is retransmitted
> 3) When the connection terminates
> 4) When a packet is sent
> 5) When a packet is received
>
> Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
> ---
> include/linux/tcp.h | 8 ++++++++
> include/uapi/linux/bpf.h | 1 +
> net/core/filter.c | 7 +++++++
> 3 files changed, 16 insertions(+)
>
> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
> index 4f93f095..62f4388 100644
> --- a/include/linux/tcp.h
> +++ b/include/linux/tcp.h
> @@ -373,6 +373,14 @@ struct tcp_sock {
> */
> struct request_sock *fastopen_rsk;
> u32 *saved_syn;
> +
> +/* Sock_ops bpf program related variables */
> +#ifdef CONFIG_BPF
> + u32 bpf_sock_ops_flags; /* values defined in uapi/linux/tcp.h */
> +#define BPF_SOCK_OPS_TEST_FLAG(TP, ARG) (TP->bpf_sock_ops_flags & ARG)
> +#else
> +#define BPF_SOCK_OPS_TEST_FLAG(TP, ARG) 0
> +#endif
> };
>
It looks like we add yet another TCP socket field for some feature that
is only used by you or FB :/
At least please try to fill a hole (on 64bit kernels), instead of
adding one more.
Also, should not we reject attempts to use bits that are not yet
supported by the kernel ?
If a BPF filter expects to be called for every retransmit, but kernel
is too old, this wont work.
next prev parent reply other threads:[~2018-01-09 23:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-09 21:06 [PATCH bpf-next v5 00/11] bpf: More sock_ops callbacks Lawrence Brakmo
2018-01-09 21:06 ` [PATCH bpf-next v5 01/11] bpf: Make SOCK_OPS_GET_TCP size independent Lawrence Brakmo
2018-01-09 21:06 ` [PATCH bpf-next v5 02/11] bpf: Make SOCK_OPS_GET_TCP struct independent Lawrence Brakmo
2018-01-09 21:06 ` [PATCH bpf-next v5 03/11] bpf: Add write access to tcp_sock and sock fields Lawrence Brakmo
2018-01-09 23:21 ` Eric Dumazet
2018-01-09 23:41 ` Lawrence Brakmo
2018-01-09 21:06 ` [PATCH bpf-next v5 04/11] bpf: Support passing args to sock_ops bpf function Lawrence Brakmo
2018-01-09 21:06 ` [PATCH bpf-next v5 05/11] bpf: Adds field bpf_sock_ops_flags to tcp_sock Lawrence Brakmo
2018-01-09 23:30 ` Eric Dumazet [this message]
2018-01-10 0:31 ` Lawrence Brakmo
2018-01-09 21:06 ` [PATCH bpf-next v5 06/11] bpf: Add sock_ops RTO callback Lawrence Brakmo
2018-01-09 21:07 ` [PATCH bpf-next v5 07/11] bpf: Add support for reading sk_state and more Lawrence Brakmo
2018-01-09 21:07 ` [PATCH bpf-next v5 08/11] bpf: Add sock_ops R/W access to tclass & sk_txhash Lawrence Brakmo
2018-01-09 21:07 ` [PATCH bpf-next v5 09/11] bpf: Add BPF_SOCK_OPS_RETRANS_CB Lawrence Brakmo
2018-01-09 21:07 ` [PATCH bpf-next v5 10/11] bpf: Add BPF_SOCK_OPS_STATE_CB Lawrence Brakmo
2018-01-09 21:07 ` [PATCH bpf-next v5 11/11] bpf: add selftest for tcpbpf Lawrence Brakmo
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=1515540628.131759.15.camel@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=ast@fb.com \
--cc=bmatheny@fb.com \
--cc=brakmo@fb.com \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=ycheng@google.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.