Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1172283AbdDXVbf (ORCPT ); Mon, 24 Apr 2017 17:31:35 -0400 Received: from mail-oi0-f53.google.com ([209.85.218.53]:34624 "EHLO mail-oi0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S977149AbdDXVb1 (ORCPT ); Mon, 24 Apr 2017 17:31:27 -0400 MIME-Version: 1.0 In-Reply-To: References: From: =?UTF-8?Q?Lars_Erik_Storbuk=C3=A5s?= Date: Mon, 24 Apr 2017 23:31:25 +0200 Message-ID: Subject: Re: Get amount of fast retransmissions from TCP info To: Neal Cardwell Cc: LKML , Netdev Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v3OLVnLH000623 Content-Length: 3312 Lines: 87 2017-04-24 23:00 GMT+02:00 Neal Cardwell : > On Mon, Apr 24, 2017 at 4:20 PM, Lars Erik Storbukås > wrote: >> 2017-04-24 21:42 GMT+02:00 Neal Cardwell : >>> On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås >>> wrote: >>>> I'm trying to get amount of congestion events in TCP caused by >>>> DUPACK's (fast retransmissions), and can't seem to find any variable >>>> in the TCP info struct which hold that value. There are three >>>> variables in the TCP info struct that seem to hold similar congestion >>>> values: __u8 tcpi_retransmits;__u32 tcpi_retrans; __u32 >>>> tcpi_total_retrans; >>>> >>>> Does anyone have any pointers on how to find this value in the TCP code? >>>> >>>> Please CC me personally if answering this question. Any help is >>>> greatly appreciated. >>> >>> [I'm cc-ing the netdev list.] >>> >>> Do you need this per-socket? On a per-socket basis, I do not think >>> there are separate totals for fast retransmits and timeout >>> retransmits. >>> >>> If a global number is good enough, then you can get that number from >>> the global network statistics. In "nstat" output they look like: >>> >>> TcpExtTCPFastRetrans = packets sent in fast retransmit / fast recovery >>> >>> TcpExtTCPSlowStartRetrans = packets sent in timeout recovery >>> >>> It sounds like TcpExtTCPFastRetrans is what you are after. >>> >>> Hope that helps, >>> neal >> >> Thanks for your answer Neal. >> >> Yes, I need this information per-socket. What would be the most >> appropriate place to update this value? > > Is this for a custom kernel you are building? Or are you proposing > this for upstream? This is currently for a custom kernel. > IMHO the best place to add this for your custom kernel would be in > _tcp_retransmit_skb() around the spot with the comment "Update global > and local TCP statistics". Something like: > > /* Update global and local TCP statistics. */ > ... > tp->total_retrans += segs; > if (icsk->icsk_ca_state == TCP_CA_Loss) > tp->slow_retrans += segs; > else > tp->fast_retrans += segs; > Excellent. That seems like a logical place. >> If none of the variables (mentioned above) contain any value in >> regards to fast retransmits, what does the different values represent? > > tcpi_retransmits: consecutive retransmits of lowest-sequence outstanding packet > > tcpi_retrans: retransmitted packets estimated to be in-flight in the network now > > tcpi_total_retrans: total number of retransmitted packets over the > life of the connection > > Can you sketch out why you need to have separate counts for fast > retransmits and timeout/slow-start retransmits? > > neal I'm working on the implementation of a Deadline Aware, Less than Best Effort framework proposed by David A. Hayes, David Ros, Andreas Petlund. A framework for adding both LBE behaviour and awareness of “soft” delivery deadlines to any congestion control (CC) algorithm, whether loss-based, delay- based or explicit signaling-based. This effectively allows it to turn an arbitrary CC protocol into a scavenger protocol that dynamically adapts its sending rate to network conditions and remaining time before the deadline, to balance timeliness and transmission aggressiveness. /Lars Erik