BPF tcp_ops gains AutoLOWAT hooks to cut RPC wakeups

Kuniyuki Iwashima has posted a fourth revision of a bpf-next series that adds per-socket bpf_tcp_ops hooks so BPF can implement TCP AutoLOWAT: dynamically raising and lowering a socket's receive low-water mark to suppress EPOLLIN wakeups until a full application frame is queued.

The new enqueue and dequeue receive-queue callbacks fire when the TCP stack puts data on, or cleans data from, the socket receive queue. A companion kfunc enables the feature with a flag on individual sockets. A BPF program can then parse framing (for example an RPC length prefix) in the kernel and adjust the low-water mark so the application wakes once per frame instead of once per packet, and without the extra setsockopt round trips SO_RCVLOWAT normally forces.

The technique was built at Google in 2020 for internal RPC workloads and has run in production for more than five years. Paired with TCP receive zerocopy, it typically lets a service read an entire RPC frame with one wakeup and one system call. The original code was specialized to Google's RPC format; the series generalizes it through BPF. Legacy SOCK_OPS programs do not get the new callbacks.

The same series also adds a u32 per-socket flag word and an atomic kfunc to set it, because even a bpf_tcp_ops attachment with NULL fast-path callbacks was measured to cost cycles. Existing header-parse, header-write, and RTT hooks are gated behind the new flags, and SOCK_OPS paths get a similar static-key check so cold flag loads are skipped when nothing is attached. MPTCP subflows are excluded from the receive-queue flag for now.

Stanislav Fomichev and Amery Hung have acked or reviewed the core patches. Automated review flagged a high-severity concern that a new low-water kfunc accepts a generic sock and could mis-touch non-TCP sockets, plus a medium selftest state-reset issue; those remain open against the v4 posting.