Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH net-next] tcp: expose sk_state in tcp_retransmit_skb
 tracepoint
To:     Yafang Shao <laoar.shao@gmail.com>, edumazet@google.com,
        davem@davemloft.net
Cc:     netdev@vger.kernel.org, linux-kernel@vger.kernel.org
References: <1537732141-22468-1-git-send-email-laoar.shao@gmail.com>
From:   Eric Dumazet <eric.dumazet@gmail.com>
Message-ID: <375c389d-f391-5b72-bc52-9a82d61c6bd7@gmail.com>
Date:   Sun, 23 Sep 2018 14:42:30 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <1537732141-22468-1-git-send-email-laoar.shao@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 09/23/2018 12:49 PM, Yafang Shao wrote:
> With sk_state, we can know whether this connection is in SYN_SENT state
> or ESTBLISHED state.
> The reason to distinguish between these two scenario is that the
> retransmission in ESTABLISHED state always mean network congestion while
> in SYN_SENT state it always mean server issue, i.e. the syn packet is
> dropped due to syn backlog queue full.

You mean, a packet drop on the remote peer ?

It could also be a packet drop in the network.

Your patch is good, but changelog is quite misleading.