sched: Use the socket RTT in KIST to compute a more accurate extra space
This comes from a discussion in #24665 (moved) that Yawning started:
Assuming the scheduler is called significantly faster than the RTT of most links (read that as "If 10 ms is lower than the RTT of most if not all links"), you can/should reduce sock_buf_size_factor as well, because you aren't going to get a full congestion window worth of ACKs back between scheduler calls in common cases.
There isn't a good "one size fits all" solution. Setting it too low will gimp performance on fast low latency links, setting it too high right now bloats the various buffers. I would personally opt more toward avoiding the latter given all the Fun that's happening.
In the struct tcp_info
we use in KIST, tcpi_rtt
gives the smoothed RTT estimate (and tcpi_rttvar
the RTT variance if you need it), which is probably sufficient to give a better reasonable guess here, as a first pass, I would recommend doing something based on the the scheduler interval to smoothed RTT ratio, with a hard maximum at 1.0.