From patchwork Fri Feb 1 05:45:59 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: yupeng X-Patchwork-Id: 1034596 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="G4A6Q94T"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 43rR0q6sZWz9s4V for ; Fri, 1 Feb 2019 16:46:03 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726653AbfBAFqC (ORCPT ); Fri, 1 Feb 2019 00:46:02 -0500 Received: from mail-pf1-f196.google.com ([209.85.210.196]:43728 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726339AbfBAFqC (ORCPT ); Fri, 1 Feb 2019 00:46:02 -0500 Received: by mail-pf1-f196.google.com with SMTP id w73so2611468pfk.10 for ; Thu, 31 Jan 2019 21:46:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=8B9R+D296PvMJtpiXcZUegOXEVb+L7VsNICeq58pylQ=; b=G4A6Q94TYBRipVdmKgshhawTUhvyovHGzG+kDYrC8YbPukYpmRmCLUrDcLdnlA/f63 7Na8ORXapuyRuMIqQDGpJHcSVnVh17fI76a+4IUfnMF9UWUMnduEfRuet/5KtXiDQPUS Kl+/dLvGBuR9L42BoAnNhSOZt4o0qudaEJLnXohb617gSzp+m8rBCGt+tqtc8UZpt2Ju VkJ8da7BwaZc2PZ0BLM9vOePmhClG8AyrV91LjP2KzXo0bGwOmmxFDJas5uEB2ePDWND XOeeI5IuM/X0Vor33i106S6wiFC2A3lFmi6WlbfYsVuJkG2ELhwDWrPJyGc1ZswWJMp9 g23A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=8B9R+D296PvMJtpiXcZUegOXEVb+L7VsNICeq58pylQ=; b=lndiBgmZ27WCSiL8EK1ivOaT+CMqaTd5XhWNSVwOR7XygkounHWsqI1UQwxSYaE0hA NfLFnY9oyk++zPF0xlxRU5C3vLl9wixmwxBpr7dYb2OP1GDscibZ1UQ9gMMaYiWdJX3p KqlprdGu2HcW5WCZ4h2X2P/HwulEe+CRyrzvFbeD3dkmK33z9byzWRACYdPlYNE1cUwc 0OM+cHx6xIJgENZpwPaUah7/bjSO93BvnGc/s7KPZTgn0AuLOaRDzUK1GizuDFzZe6lo tkpr1VwEAM/bhdcj9RgPntaw6c5EopThECIzVhQzDVcd9boBuO7x4w5TWtBk/a6KIiLT eA2Q== X-Gm-Message-State: AJcUukeDINdgH4/Z5WVKBScA54HcmKFekYCAOPM3pllk64m7vXb+siDd z21bo6o11w9MvwjU5PPlgtFybtje X-Google-Smtp-Source: ALg8bN4BqZfAFgYyPQsA5Lqs0JYdzoicePgRNKtcYtrnfTu75YTxYati+j0fuA+9Hm1SVT3AaSXLvQ== X-Received: by 2002:a62:6e07:: with SMTP id j7mr38924946pfc.135.1548999960703; Thu, 31 Jan 2019 21:46:00 -0800 (PST) Received: from localhost.localdomain ([2601:602:9602:6598:24fc:77da:1d79:279f]) by smtp.gmail.com with ESMTPSA id y71sm18833909pfi.123.2019.01.31.21.45.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Jan 2019 21:46:00 -0800 (PST) From: yupeng To: netdev@vger.kernel.org, davem@davemloft.net Cc: xiyou.wangcong@gmail.com, rdunlap@infradead.org Subject: [PATCH net] add snmp counter document Date: Thu, 31 Jan 2019 21:45:59 -0800 Message-Id: <20190201054559.8082-1-yupeng0921@gmail.com> X-Mailer: git-send-email 2.17.1 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org add document for tcp retransmission, tcp fast open, syn cookies, challenge ack, prune and several general counters Signed-off-by: yupeng --- Documentation/networking/snmp_counter.rst | 143 ++++++++++++++++++++++ 1 file changed, 143 insertions(+) diff --git a/Documentation/networking/snmp_counter.rst b/Documentation/networking/snmp_counter.rst index fe8f741193be..8520c500d4e5 100644 --- a/Documentation/networking/snmp_counter.rst +++ b/Documentation/networking/snmp_counter.rst @@ -354,6 +354,26 @@ process might be failed due to some errors (e.g. memory alloc failed). .. _RFC1213 tcpOutRsts: https://tools.ietf.org/html/rfc1213#page-52 +* TcpExtTCPSpuriousRtxHostQueues +When the TCP stack wants to retransmit a packet, and finds that packet +is not lost in the network, but the packet is not sent yet, the TCP +stack would give up the retransmission and update this counter. It +might happen if a packet stays too long time in a qdisc or driver +queue. + +* TcpEstabResets +The socket receives a RST packet in Establish or CloseWait state. + +* TcpExtTCPKeepAlive +This counter indicates many keepalive packets were sent. The keepalive +won't be enabled by default. A userspace program could enable it by +setting the SO_KEEPALIVE socket option. + +* TcpExtTCPSpuriousRTOs +The spurious retransmission timeout detected by the `F-RTO`_ +algorithm. + +.. _F-RTO: https://tools.ietf.org/html/rfc5682 TCP Fast Path ============ @@ -562,6 +582,24 @@ packet yet, the sender would know packet 4 is out of order. The TCP stack of kernel will increase TcpExtTCPSACKReorder for both of the above scenarios. +* TcpExtTCPSlowStartRetrans +The TCP stack wants to retransmit a packet and the congestion control +state is 'Loss'. + +* TcpExtTCPFastRetrans +The TCP stack wants to retransmit a packet and the congestion control +state is not 'Loss'. + +* TcpExtTCPLostRetransmit +A SACK points out that a retransmission packet is lost again. + +* TcpExtTCPRetransFail +The TCP stack tries to deliver a retransmission packet to lower layers +but the lower layers return an error. + +* TcpExtTCPSynRetrans +The TCP stack retransmits a SYN packet. + DSACK ===== The DSACK is defined in `RFC2883`_. The receiver uses DSACK to report @@ -783,6 +821,111 @@ A TLP probe packet is sent. * TcpExtTCPLossProbeRecovery A packet loss is detected and recovered by TLP. +TCP Fast Open +============ +TCP Fast Open is a technology which allows data transfer before the +3-way handshake complete. Please refer the `TCP Fast Open wiki`_ for a +general description. + +.. _TCP Fast Open wiki: https://en.wikipedia.org/wiki/TCP_Fast_Open + +* TcpExtTCPFastOpenActive +When the TCP stack receives an ACK packet in the SYN-SENT status, and +the ACK packet acknowledges the data in the SYN packet, the TCP stack +understand the TFO cookie is accepted by the other side, then it +updates this counter. + +* TcpExtTCPFastOpenActiveFail +This counter indicates that the TCP stack initiated a TCP Fast Open, +but it failed. This counter would be updated in three scenarios: (1) +the other side doesn't acknowledge the data in the SYN packet. (2) The +SYN packet which has the TFO cookie is timeout at least once. (3) +after the 3-way handshake, the retransmission timeout happens +net.ipv4.tcp_retries1 times, because some middle-boxes may black-hole +fast open after the handshake. + +* TcpExtTCPFastOpenPassive +This counter indicates how many times the TCP stack accepts the fast +open request. + +* TcpExtTCPFastOpenPassiveFail +This counter indicates how many times the TCP stack rejects the fast +open request. It is caused by either the TFO cookie is invalid or the +TCP stack finds an error during the socket creating process. + +* TcpExtTCPFastOpenListenOverflow +When the pending fast open request number is larger than +fastopenq->max_qlen, the TCP stack will reject the fast open request +and update this counter. When this counter is updated, the TCP stack +won't update TcpExtTCPFastOpenPassive or +TcpExtTCPFastOpenPassiveFail. The fastopenq->max_qlen is set by the +TCP_FASTOPEN socket operation and it could not be larger than +net.core.somaxconn. For example: + +setsockopt(sfd, SOL_TCP, TCP_FASTOPEN, &qlen, sizeof(qlen)); + +* TcpExtTCPFastOpenCookieReqd +This counter indicates how many times a client wants to request a TFO +cookie. + +SYN cookies +========== +SYN cookies are used to mitigate SYN flood, for details, please refer +the `SYN cookies wiki`_. + +.. _SYN cookies wiki: https://en.wikipedia.org/wiki/SYN_cookies + +* TcpExtSyncookiesSent +It indicates how many SYN cookies are sent. + +* TcpExtSyncookiesRecv +How many reply packets of the SYN cookies the TCP stack receives. + +* TcpExtSyncookiesFailed +The MSS decoded from the SYN cookie is invalid. When this counter is +updated, the received packet won't be treated as a SYN cookie and the +TcpExtSyncookiesRecv counter wont be updated. + +Challenge ACK +============ +For details of challenge ACK, please refer the explaination of +TcpExtTCPACKSkippedChallenge. + +* TcpExtTCPChallengeACK +The number of challenge acks sent. + +* TcpExtTCPSYNChallenge +The number of challenge acks sent in response to SYN packets. After +updates this counter, the TCP stack might send a challenge ACK and +update the TcpExtTCPChallengeACK counter, or it might also skip to +send the challenge and update the TcpExtTCPACKSkippedChallenge. + +prune +===== +When a socket is under memory pressure, the TCP stack will try to +reclaim memory from the receiving queue and out of order queue. One of +the reclaiming method is 'collapse', which means allocate a big sbk, +copy the contiguous skbs to the single big skb, and free these +contiguous skbs. + +* TcpExtPruneCalled +The TCP stack tries to reclaim memory for a socket. After updates this +counter, the TCP stack will try to collapse the out of order queue and +the receiving queue. If the memory is still not enough, the TCP stack +will try to discard packets from the out of order queue (and update the +TcpExtOfoPruned counter) + +* TcpExtOfoPruned +The TCP stack tries to discard packet on the out of order queue. + +* TcpExtRcvPruned +After 'collapse' and discard packets from the out of order queue, if +the actually used memory is still larger than the max allowed memory, +this counter will be updated. It means the 'prune' fails. + +* TcpExtTCPRcvCollapsed +This counter indicates how many skbs are freed during 'collapse'. + examples =======