On Wed, Sep 11, 2019 at 6:32 PM Thomas Higdon <t...@fb.com> wrote: > > Neal Cardwell mentioned that rcv_wnd would be useful for helping > diagnose whether a flow is receive-window-limited at a given instant. > > This serves the purpose of adding an additional __u32 to avoid the > would-be hole caused by the addition of the tcpi_rcvi_ooopack field. > > Signed-off-by: Thomas Higdon <t...@fb.com> > ---
Thanks, Thomas. I know that when I mentioned this before I mentioned the idea of both tp->snd_wnd (send-side receive window) and tp->rcv_wnd (receive-side receive window) in tcp_info, and did not express a preference between the two. Now that we are faced with a decision between the two, personally I think it would be a little more useful to start with tp->snd_wnd. :-) Two main reasons: (1) Usually when we're diagnosing TCP performance problems, we do so from the sender, since the sender makes most of the performance-critical decisions (cwnd, pacing, TSO size, TSQ, etc). >From the sender-side the thing that would be most useful is to see tp->snd_wnd, the receive window that the receiver has advertised to the sender. (2) From the receiver side, "ss" can already show a fair amount of info about receive-side buffer/window limits, like: info->tcpi_rcv_ssthresh, info->tcpi_rcv_space, skmeminfo[SK_MEMINFO_RMEM_ALLOC], skmeminfo[SK_MEMINFO_RCVBUF]. Often the rwin can be approximated by combining those. Hopefully Eric, Yuchung, and Soheil can weigh in on the question of snd_wnd vs rcv_wnd. Or we can perhaps think of another field, and add the tcpi_rcvi_ooopack, snd_wnd, rcv_wnd, and that final field, all together. thanks, neal
