Changed
tcp_packet_latencycosts less per segment and per read. It kept
each socket's start time in a hash map: every data segment attempted an
insert, taking the bucket lock, and a read that found an entry deleted it.
It now keeps them in a fixed 4 MiB array of one-word slots indexed by a
hash of the socket's address, and attachestp_btfprograms where the
kernel hasbpf_skc_to_tcp_sock(5.9+),raw_tpotherwise. In a 6.12 VM
over loopback (valkey-benchmark 4 KiB SET/GET, 48 clients, one run per
arm), ns per run fortcp_probe/tcp_rcv_space_adjustwent from
393 / 598 to 254 / 364 withtp_btfand to 296 / 307 withraw_tp.- Only an in-order data segment (sequence number
rcv_nxt) starts a
sample. Duplicate, out-of-order and beyond-window segments used to, and
a dropped one could leave a start time that a much later read recorded.
An in-order segment the kernel then drops still starts one, as before. - A segment whose slot holds another socket's start time is not timed:
about K / 2^19 of segments when K sockets hold a start time at once
(0.20-0.22% of samples at 2000 clients against an exact reference).
When a later in-order segment arrives before the read, the sample
starts there and is shorter than the data's wait. - The old map stopped timing new sockets once 10240 held a start time;
misses now grow with K instead (about 2% at K = 10240).
- Only an in-order data segment (sequence number