Skip to content

RFC Extensions to allow asynchronous TCP_INFO notifications based on congestion parameters

Sowmini Varadhan netdev 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 RFC Latest3 patches 0 repliesNew

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/3sock_diag: Refactor inet_sock_diag_destroy codeinclude/linux/sock_diag.h include/uapi/linux/sock_diag.h net/core/sock.c +1 more+23 -120 replies
2/3tcp: BPF_TCP_INFO_NOTIFY supportinclude/net/tcp.h include/uapi/linux/bpf.h+17 -20 replies
3/3bpf: Added a sample for tcp_info_notify callbacksamples/bpf/Makefile samples/bpf/tcp_notify_kern.c+74 -00 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH RFC net-next 0/3] Extensions to allow asynchronous TCP_INFO notifications based on congestion parameters

Problem statement:
We would like to monitor some subset of TCP sockets in user-space, (the monitoring application would define 4-tuples it wants to monitor) using TCP_INFO stats to analyze reported problems. The idea is to use those stats to see where the bottlenecks are likely to be ("is it application-limited?" or "is there evidence of BufferBloat in the path?" etc)

Today we can do this by periodically polling for tcp_info, but this could be made more efficient if the kernel would asynchronously notify the application via tcp_info when some "interesting" thresholds (e.g., "RTT variance > X", or "total_retrans > Y" etc) are reached. And to make this effective, it is better if we could apply the threshold check *before* constructing the tcp_info netlink notification, so that we don't waste resources constructing notifications that will be discarded by the filter.

One idea, implemented in this patchset, is to extend the tcp_call_bpf() infra so that the BPF kernel module (the sock_ops filter/callback) can examine the values in the sock_ops, apply any thresholds it wants, and return some new status ("BPF_TCP_INFO_NOTIFY"). Use this status in the tcp stack to queue up a tcp_info notification (similar to sock_diag_broadcast_destroy() today..)

Patch 1 in this set refactors the existing sock_diag code so that the functions can be reused for notifications from other states than CLOSE.

Patch 2 provides a minor extension to tcp_call_bpf() so that it will queue a tcp_info_notification if the BPF callout returns BPF_TCP_INFO_NOTIFY

Patch 3, provided strictly as a demonstration/PoC to aid in reviewing this proposal, shows a simple sample/bpf example where we trigger the tcp_info notification for an iperf connection if the number of retransmits exceeds 16.

Sowmini Varadhan (3):
sock_diag: Refactor inet_sock_diag_destroy code
tcp: BPF_TCP_INFO_NOTIFY support
bpf: Added a sample for tcp_info_notify callback

 include/linux/sock_diag.h      |   18 +++++++---
 include/net/tcp.h              |   15 +++++++-
 include/uapi/linux/bpf.h       |    4 ++
 include/uapi/linux/sock_diag.h |    2 +
 net/core/sock.c                |    4 +-
 net/core/sock_diag.c           |   11 +++---
 samples/bpf/Makefile           |    1 +
 samples/bpf/tcp_notify_kern.c  |   73 ++++++++++++++++++++++++++++++++++++++++
 8 files changed, 114 insertions(+), 14 deletions(-)
 create mode 100644 samples/bpf/tcp_notify_kern.c