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.
PS: SYNACK retransmission is traced in tcp_retransmit_synack tracepoint.
Signed-off-by: Yafang Shao <[email protected]>
---
include/trace/events/tcp.h | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/trace/events/tcp.h b/include/trace/events/tcp.h
index ac55b32..2bc9960 100644
--- a/include/trace/events/tcp.h
+++ b/include/trace/events/tcp.h
@@ -56,6 +56,7 @@
TP_STRUCT__entry(
__field(const void *, skbaddr)
__field(const void *, skaddr)
+ __field(int, state)
__field(__u16, sport)
__field(__u16, dport)
__array(__u8, saddr, 4)
@@ -70,6 +71,7 @@
__entry->skbaddr = skb;
__entry->skaddr = sk;
+ __entry->state = sk->sk_state;
__entry->sport = ntohs(inet->inet_sport);
__entry->dport = ntohs(inet->inet_dport);
@@ -84,9 +86,10 @@
sk->sk_v6_rcv_saddr, sk->sk_v6_daddr);
),
- TP_printk("sport=%hu dport=%hu saddr=%pI4 daddr=%pI4 saddrv6=%pI6c daddrv6=%pI6c",
+ TP_printk("sport=%hu dport=%hu saddr=%pI4 daddr=%pI4 saddrv6=%pI6c daddrv6=%pI6c state=%s\n",
__entry->sport, __entry->dport, __entry->saddr, __entry->daddr,
- __entry->saddr_v6, __entry->daddr_v6)
+ __entry->saddr_v6, __entry->daddr_v6,
+ show_tcp_state_name(__entry->state))
);
DEFINE_EVENT(tcp_event_sk_skb, tcp_retransmit_skb,
--
1.8.3.1
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.
On Mon, Sep 24, 2018 at 5:42 AM, Eric Dumazet <[email protected]> wrote:
>
>
> 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 ?
>
Yes, I mean drop on the remote peer.
> It could also be a packet drop in the network.
>
Yes of course.
> Your patch is good, but changelog is quite misleading.
Will modify the changelog.
Thanks
Yafang