From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5310C49ED6 for ; Thu, 12 Sep 2019 00:50:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A258D20872 for ; Thu, 12 Sep 2019 00:50:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="WH60mGYO" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728671AbfILAuO (ORCPT ); Wed, 11 Sep 2019 20:50:14 -0400 Received: from mail-ot1-f66.google.com ([209.85.210.66]:35745 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728635AbfILAuO (ORCPT ); Wed, 11 Sep 2019 20:50:14 -0400 Received: by mail-ot1-f66.google.com with SMTP id t6so11198453otp.2 for ; Wed, 11 Sep 2019 17:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jBuwKfPWS97eqadXQTiWuQEBpm2jfqWFYrr+X2k1sgg=; b=WH60mGYObp8VaoD1CSfrn5CpE2t8TCA/Pi4FB06QRUtopb/hzHLchaIa0hC4dlmNXQ smoX3sGkAioGtYcrabQkMGGZ1AwO/HTB0RzkhoTQ7rqiQM27Wka9bE7zGzca+EvACNkB H04KxbtCZE8/TZEL/5ovYm5eLBmphZEzw8yJmrz6V/xorSuKvzWWT5HwSQXHEl+H03i2 I4W5U35xBE08EgtSjKvCiGwslDVCSWxJbVbcAXFtBmVf0ooSrm3FN88soSkl2eOecHQf ccy7v50fM8Bcc+aClAOmuKYf42r39VUE2qhJ7W902IHT4aI8lRlkhvgQq8bpoY5O+a1/ rwzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jBuwKfPWS97eqadXQTiWuQEBpm2jfqWFYrr+X2k1sgg=; b=KQj1o8LTiQUN+R6MwSjJvvIvC0AsIdb3MHYmPRyGboRTs45gK5BUZqOZGg4vk1XagH iYDt1xQSIB/FQ+F82eIE0BgwtO8dChSNwFzvbDVadA4hryVnb9L1oObalvWZwz0s4TpO oC6RvatT1RoqYEP9Th58mXxDi8uSSu7cRNZ+NkUie6d//YvEGahmyT+heV9owthwQhLw V7Bx3GpVSKYSvuA0A2+oq4k0OUkGZUc/rA86/1hsPPtgJ7b7O1+WUtRBgeOlsNtZahSw eLz5qcyIDpEXT8aJ26I6iJnHHwir4v2+RPjC7SqZveky8Jp9bvC84aNkV0evpSSxc3Ch d/hQ== X-Gm-Message-State: APjAAAWH51YRMjnP4HbRFqsKtneFon+fM0/YOmLXxJn/+ysTTvYlJQQA +a1F5y6413iTU9qET/xvyr6goiSbDQjYs1V9IUFN6A== X-Google-Smtp-Source: APXvYqxlRhuAbI6Nbd3c9yrHfE2WdPDhpeNiNSJ71L5Pk6eF4zSujOAZPvJWfKBKvtlDQWeMi8XNLM+dK5pMxDVdHuE= X-Received: by 2002:a9d:6190:: with SMTP id g16mr10749060otk.302.1568249412961; Wed, 11 Sep 2019 17:50:12 -0700 (PDT) MIME-Version: 1.0 References: <20190911223148.89808-1-tph@fb.com> <20190911223148.89808-2-tph@fb.com> In-Reply-To: <20190911223148.89808-2-tph@fb.com> From: Neal Cardwell Date: Wed, 11 Sep 2019 20:49:56 -0400 Message-ID: Subject: Re: [PATCH v3 2/2] tcp: Add rcv_wnd to TCP_INFO To: Thomas Higdon Cc: "netdev@vger.kernel.org" , Jonathan Lemon , Dave Jones , Eric Dumazet , Yuchung Cheng , Soheil Hassas Yeganeh Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Sep 11, 2019 at 6:32 PM Thomas Higdon 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 > --- 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