On Thu, Oct 15, 2026 at 1:51 AM Jakub Sitnicki <[email protected]> wrote: > > On Tue, Oct 13, 2026 at 10:39 AM GMT, Willem Ferguson wrote: > > Let a sock_ops program pick the identifier that the previous patch > > encodes in the low bits of TSval, for passively opened connections. > > > > The width is set per network namespace by the new tcp_ts_id_bits sysctl > > (0 to 8, default 0). A listener opts in by setting > > BPF_SOCK_OPS_TCP_TS_ID_CB_FLAG, typically from BPF_SOCK_OPS_TCP_LISTEN_CB. > > tcp_conn_request() then runs BPF_SOCK_OPS_TCP_TS_ID_CB once the request > > socket exists and before the SYN-ACK is built, so the SYN-ACK already > > carries the identifier. The program sees the request socket, the SYN > > (bpf_load_hdr_opt() works on it) and the available width in args[1]. A > > reply that fits in that width is stored with the width in the request > > socket and is inherited by the child, including Fast Open children; any > > other reply leaves the connection unencoded. > > > > The callback is not run for SYN cookies, which have nowhere to keep the > > identifier, or when the peer did not negotiate timestamps. It is skipped > > for connections using microsecond timestamps and while the sysctl is 0. > > The width is captured per connection, so changing the sysctl does not > > affect existing connections. > > > > New /proc/net/netstat counters report how often an identifier was > > assigned, declined by the program or skipped. TCPTSIdEchoMismatch counts > > third ACKs whose TSecr no longer carries the identifier, which shows the > > echo was rewritten in flight. > > > > BPF_SOCK_OPS_ALL_CB_FLAGS grows from 0x7f to 0xff. The tcpbpf selftest > > used 0x80 as an example of an unsupported flag, so move it to 0x100. > > > > Encoding makes the timestamp clock appear 2^bits times faster to the > > peer. That shrinks the real-time span of the peer's PAWS window, and > > peers that keep ts_recent for the RFC 7323 24 days stall connections > > idle for longer than 24.8/2^bits days. ip-sysctl.rst documents both, > > along with the lack of TCP_REPAIR support. > > > > Signed-off-by: Willem Ferguson <[email protected]> > > --- > > I think SOCK_OPS are considered legacy. > We probably want bpf_tcp_ops struct_ops. > See [1] for an example. > > [1] https://lore.kernel.org/all/[email protected]/ >
Exactly! Thanks, Jason
