On Mon, Mar 10, 2025 at 2:20 AM Andrew Easton <Andrew@xxxxxxxxxxxx> wrote: > > Subject: Add sysctl for tcp_delayed_ack > > Hi everyone, Hi Andrew > > this is a proposed patch for adding a sysctl for > disabling TCP delayed ACK (IETF RFC 1122) without > having to patch software to constantly poke sockets > with TCP_QUICKACK which apparently resets on > subsequent operations, see tcp(7). > > For my personal computer networks experimenting with > globally disabling TCP delayed ACK across two other > operating systems seems to have considerably improved > congestion control. (While I propose only anecdotal > evidence, there is more to it. Am open to the > ensuing technical discussion, but only if that turns > out to be a good use of other people's time.) > > This is my first proposed kernel patch and it is > likely missing a whole bunch of details. For > example: > > 1. Where is the TCP ACK delay computed for IPv6? > Could not identify this in file net/ipv6/tcp_ipv6.c . No need to change tcp_ipv6.c Generating ACK is generic, thus code is in net/ipv4 > > 2. Perhaps, adding kernel configuration options for > the ncurses interface is desireable. What is a good > example to learn from? No need. per net-ns sysctl and/or per-socket options are far better for this case. > > 3. Perhaps, setting constants in file > include/uapi/linux/sysctl.h may be unnecessary, but I > have not found any guidelines on when these CTL > numbers are necessary. Likely, because I did not > read the documentation carefully enough. Any > pointers are appreciated. sysctl.h is absolutely deprecated. No need for NET_IPV4_TCP_DELAYED_ACK, No ctl_name in 'struct ctl_table' > > 4. The default should probably be a value like > net.ipv4.tcp_delayed_ack=1 that preserves the current > behavior and hence is backwards compatible for user > space. A value of net.ipv4.tcp_delayed_ack=0 should > globally (for IPv4) disable TCP delayed ACK. Would > also like to add the option for IPv6, but see point > (1). > > > In case a similar sysctl has already been proposed > and rejected in the past, please point me to the > mailing list archives, if that is not too > inconvenient. > > > Which questions have I failed to ask that I should > have asked? > > Errors and lack of research are on me. > Make sure to compile/test your patch on top of net-next tree, and send it inline, not as an attachment, so that we can comment on it. Also next time add benchmark results like netperf -t TCP_RR (200 flows) of netper/tcp_rr -F 1000 No delaying ACK for small RPC is essentially doubling the number of packets to send and receive. > Thank you for sharing your time. > > Andrew > > > > >
