RE: [PATCH v2 0/2] Tracepoint for tcp retransmission

[Satoru Moriya <satoru.moriya@xxxxxxx>]

On 01/20/2012 01:50 PM, David Miller wrote:
> You were given an alternative way to trace these kinds of events, and 
> you have yet to give us a solid reason why that cannot work for you.

OK. I'll try to explain it.

First of all, we'd like to use this tracepoint with our
flight recorder.

tcpdump:
 tcpdump captures all the packets and so its overhead is not
 acceptable. Also we can't keep the data on memory but must
 write the data to file for each time. It introduce other
 overhead which we can't accept.

commit 63e03724b51, dropwatch, skb:kfree_skb:
 With this tracepoint, we can detect packet drop.
 But it may be too late because with tcp kernel retransmits
 packets repeatedly if it can't get ack and after that it
 may drops packets in a no-win situation.
 Also sometimes customer finds delays which is caused by
 temporal packet drop and retransmission. With this tracepoint
 we can explain it based on the real data.

netstat:
 This is a good tool for the first step to analyze what
 happened. But it shows only statistics and it's not enough
 for us to analyze incidents and explain it to our customers.
 We need each packet drop data(when it happen, whether it
 succeeded or not etc.)

systemtap:
 Actually, we've already used systemtap in our flight recorder.
 But we believe that tcp retransmission is one of the fundamental
 function in tcp stack and so kernel itself should provide the
 instruments from which we can get enough information.

Regards,
Satoru
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html