Netdev List
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Lawrence Brakmo <brakmo@fb.com>
Cc: netdev <netdev@vger.kernel.org>, Kernel Team <kernel-team@fb.com>,
	Blake Matheny <bmatheny@fb.com>, Alexei Starovoitov <ast@fb.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Neal Cardwell <ncardwell@google.com>,
	Yuchung Cheng <ycheng@google.com>
Subject: Re: [PATCH bpf-next v10 00/12] bpf: More sock_ops callbacks
Date: Thu, 25 Jan 2018 16:54:39 -0800	[thread overview]
Message-ID: <20180126005437.2rzbypi3mlqj6a33@ast-mbp> (raw)
In-Reply-To: <20180126001416.1118158-1-brakmo@fb.com>

On Thu, Jan 25, 2018 at 04:14:04PM -0800, Lawrence Brakmo wrote:
> This patchset adds support for:
> 
> - direct R or R/W access to many tcp_sock fields
> - passing up to 4 arguments to sock_ops BPF functions
> - tcp_sock field bpf_sock_ops_cb_flags for controlling callbacks
> - optionally calling sock_ops BPF program when RTO fires
> - optionally calling sock_ops BPF program when packet is retransmitted
> - optionally calling sock_ops BPF program when TCP state changes
> - access to tclass and sk_txhash
> - new selftest
> 
> v2: Fixed commit message 0/11. The commit is to "bpf-next" but the patch
>     below used "bpf" and Patchwork didn't work correctly.
> v3: Cleaned RTO callback as per  Yuchung's comment
>     Added BPF enum for TCP states as per  Alexei's comment
> v4: Fixed compile warnings related to detecting changes between TCP
>     internal states and the BPF defined states.
> v5: Fixed comment issues in some selftest files
>     Fixed accesss issue with u64 fields in bpf_sock_ops struct
> v6: Made fixes based on comments form Eric Dumazet:
>     The field bpf_sock_ops_cb_flags was addded in a hole on 64bit kernels
>     Field bpf_sock_ops_cb_flags is now set through a helper function
>     which returns an error when a BPF program tries to set bits for
>     callbacks that are not supported in the current kernel.
>     Added a comment indicating that when adding fields to bpf_sock_ops_kern
>     they should be added before the field named "temp" if they need to be
>     cleared before calling the BPF function.  
> v7: Enfornced fields "op" and "replylong[1] .. replylong[3]" not be writable
>     based on comments form Eric Dumazet and Alexei Starovoitov.
>     Filled 32 bit hole in bpf_sock_ops struct with sk_txhash based on
>     comments from Daniel Borkmann.
>     Removed unused functions (tcp_call_bpf_1arg, tcp_call_bpf_4arg) based
>     on comments from Daniel Borkmann.
> v8: Add commit message 00/12
>     Add Acked-by as appropriate
> v9: Moved the bug fix to the front of the patchset
>     Changed RETRANS_CB so it is always called (before it was only called if
>     the retransmit succeeded). It is now called with an extra argument, the
>     return value of tcp_transmit_skb (0 => success). Based on comments
>     from Yuchung Cheng.
>     Added support for reading 2 new fields, sacked_out and lost_out, based on
>     comments from Yuchung Cheng.
> v10: Moved the callback flags from include/uapi/linux/tcp.h to
>      include/uapi/linux/bpf.h
>      Cleaned up the test in selftest. Added a timeout so it always completes,
>      even if the client is not communicating with the server. Made it faster
>      by removing the sleeps. Made sure it works even when called back-to-back
>      20 times.

Applied to bpf-next, thank you Larry.

We'll make sure to send patch 1 to stable when 4.15 is released.

Also there were few leftover comments in patch 12,
please clean it up in the followup patch.

Thanks

      parent reply	other threads:[~2018-01-26  0:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-26  0:14 [PATCH bpf-next v10 00/12] bpf: More sock_ops callbacks Lawrence Brakmo
2018-01-26  0:14 ` [PATCH bpf-next v10 01/12] bpf: Only reply field should be writeable Lawrence Brakmo
2018-01-26  0:14 ` [PATCH bpf-next v10 02/12] bpf: Make SOCK_OPS_GET_TCP size independent Lawrence Brakmo
2018-01-26  0:14 ` [PATCH bpf-next v10 03/12] bpf: Make SOCK_OPS_GET_TCP struct independent Lawrence Brakmo
2018-01-26  0:14 ` [PATCH bpf-next v10 04/12] bpf: Add write access to tcp_sock and sock fields Lawrence Brakmo
2018-01-26  0:14 ` [PATCH bpf-next v10 05/12] bpf: Support passing args to sock_ops bpf function Lawrence Brakmo
2018-01-26  0:14 ` [PATCH bpf-next v10 06/12] bpf: Adds field bpf_sock_ops_cb_flags to tcp_sock Lawrence Brakmo
2018-01-26  0:14 ` [PATCH bpf-next v10 07/12] bpf: Add sock_ops RTO callback Lawrence Brakmo
2018-01-26  0:14 ` [PATCH bpf-next v10 08/12] bpf: Add support for reading sk_state and more Lawrence Brakmo
2018-01-26  0:14 ` [PATCH bpf-next v10 09/12] bpf: Add sock_ops R/W access to tclass Lawrence Brakmo
2018-01-26  0:14 ` [PATCH bpf-next v10 10/12] bpf: Add BPF_SOCK_OPS_RETRANS_CB Lawrence Brakmo
2018-01-26  0:14 ` [PATCH bpf-next v10 11/12] bpf: Add BPF_SOCK_OPS_STATE_CB Lawrence Brakmo
2018-01-26  0:14 ` [PATCH bpf-next v10 12/12] bpf: add selftest for tcpbpf Lawrence Brakmo
2018-01-26  0:54 ` Alexei Starovoitov [this message]

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=20180126005437.2rzbypi3mlqj6a33@ast-mbp \
    --to=alexei.starovoitov@gmail.com \
    --cc=ast@fb.com \
    --cc=bmatheny@fb.com \
    --cc=brakmo@fb.com \
    --cc=daniel@iogearbox.net \
    --cc=eric.dumazet@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox