From: David S. Miller Date: Mon, 21 Jan 2019 22:41:32 +0000 (-0800) Subject: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net X-Git-Tag: v5.1-rc1~178^2~472 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=fa7f3a8d56b38a3ed1880a3780afba82387da277;p=thirdparty%2Fkernel%2Flinux.git Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net Completely minor snmp doc conflict. Signed-off-by: David S. Miller --- fa7f3a8d56b38a3ed1880a3780afba82387da277 diff --cc Documentation/networking/snmp_counter.rst index 486ab33acc3ae,fe8f741193bec..c5642f430d2e4 --- a/Documentation/networking/snmp_counter.rst +++ b/Documentation/networking/snmp_counter.rst @@@ -364,8 -336,27 +364,29 @@@ time client replies ACK, this socket wi to the accept queue. +TCP Fast Open +============= + * TcpEstabResets + Defined in `RFC1213 tcpEstabResets`_. + + .. _RFC1213 tcpEstabResets: https://tools.ietf.org/html/rfc1213#page-48 + + * TcpAttemptFails + Defined in `RFC1213 tcpAttemptFails`_. + + .. _RFC1213 tcpAttemptFails: https://tools.ietf.org/html/rfc1213#page-48 + + * TcpOutRsts + Defined in `RFC1213 tcpOutRsts`_. The RFC says this counter indicates + the 'segments sent containing the RST flag', but in linux kernel, this + couner indicates the segments kerenl tried to send. The sending + process might be failed due to some errors (e.g. memory alloc failed). + + .. _RFC1213 tcpOutRsts: https://tools.ietf.org/html/rfc1213#page-52 + + + TCP Fast Path + ============ When kernel receives a TCP packet, it has two paths to handler the packet, one is fast path, another is slow path. The comment in kernel code provides a good explanation of them, I pasted them below:: @@@ -412,10 -401,8 +433,9 @@@ increase 1 TCP abort -======== +========= - * TcpExtTCPAbortOnData + It means TCP layer has data in flight, but need to close the connection. So TCP layer sends a RST to the other side, indicate the connection is not closed very graceful. An easy way to increase this @@@ -621,10 -589,59 +639,60 @@@ duplicate packet is received The TCP stack receives a DSACK, which indicate an out of order duplicate packet is received. + invalid SACK and DSACK + ==================== + When a SACK (or DSACK) block is invalid, a corresponding counter would + be updated. The validation method is base on the start/end sequence + number of the SACK block. For more details, please refer the comment + of the function tcp_is_sackblock_valid in the kernel source code. A + SACK option could have up to 4 blocks, they are checked + individually. E.g., if 3 blocks of a SACk is invalid, the + corresponding counter would be updated 3 times. The comment of the + `Add counters for discarded SACK blocks`_ patch has additional + explaination: + + .. _Add counters for discarded SACK blocks: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=18f02545a9a16c9a89778b91a162ad16d510bb32 + + * TcpExtTCPSACKDiscard + This counter indicates how many SACK blocks are invalid. If the invalid + SACK block is caused by ACK recording, the TCP stack will only ignore + it and won't update this counter. + + * TcpExtTCPDSACKIgnoredOld and TcpExtTCPDSACKIgnoredNoUndo + When a DSACK block is invalid, one of these two counters would be + updated. Which counter will be updated depends on the undo_marker flag + of the TCP socket. If the undo_marker is not set, the TCP stack isn't + likely to re-transmit any packets, and we still receive an invalid + DSACK block, the reason might be that the packet is duplicated in the + middle of the network. In such scenario, TcpExtTCPDSACKIgnoredNoUndo + will be updated. If the undo_marker is set, TcpExtTCPDSACKIgnoredOld + will be updated. As implied in its name, it might be an old packet. + + SACK shift + ========= + The linux networking stack stores data in sk_buff struct (skb for + short). If a SACK block acrosses multiple skb, the TCP stack will try + to re-arrange data in these skb. E.g. if a SACK block acknowledges seq + 10 to 15, skb1 has seq 10 to 13, skb2 has seq 14 to 20. The seq 14 and + 15 in skb2 would be moved to skb1. This operation is 'shift'. If a + SACK block acknowledges seq 10 to 20, skb1 has seq 10 to 13, skb2 has + seq 14 to 20. All data in skb2 will be moved to skb1, and skb2 will be + discard, this operation is 'merge'. + + * TcpExtTCPSackShifted + A skb is shifted + + * TcpExtTCPSackMerged + A skb is merged + + * TcpExtTCPSackShiftFallback + A skb should be shifted or merged, but the TCP stack doesn't do it for + some reasons. + TCP out of order -=============== +================ * TcpExtTCPOFOQueue + The TCP layer receives an out of order packet and has enough memory to queue it. @@@ -721,12 -728,66 +789,66 @@@ unacknowledged number (more strict tha .. _RFC 5961 section 4.2: https://tools.ietf.org/html/rfc5961#page-9 .. _RFC 5961 section 5.2: https://tools.ietf.org/html/rfc5961#page-11 + TCP receive window + ================= + * TcpExtTCPWantZeroWindowAdv + Depending on current memory usage, the TCP stack tries to set receive + window to zero. But the receive window might still be a no-zero + value. For example, if the previous window size is 10, and the TCP + stack receives 3 bytes, the current window size would be 7 even if the + window size calculated by the memory usage is zero. + + * TcpExtTCPToZeroWindowAdv + The TCP receive window is set to zero from a no-zero value. + + * TcpExtTCPFromZeroWindowAdv + The TCP receive window is set to no-zero value from zero. + + + Delayed ACK + ========== + The TCP Delayed ACK is a technique which is used for reducing the + packet count in the network. For more details, please refer the + `Delayed ACK wiki`_ + + .. _Delayed ACK wiki: https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment + + * TcpExtDelayedACKs + A delayed ACK timer expires. The TCP stack will send a pure ACK packet + and exit the delayed ACK mode. + + * TcpExtDelayedACKLocked + A delayed ACK timer expires, but the TCP stack can't send an ACK + immediately due to the socket is locked by a userspace program. The + TCP stack will send a pure ACK later (after the userspace program + unlock the socket). When the TCP stack sends the pure ACK later, the + TCP stack will also update TcpExtDelayedACKs and exit the delayed ACK + mode. + + * TcpExtDelayedACKLost + It will be updated when the TCP stack receives a packet which has been + ACKed. A Delayed ACK loss might cause this issue, but it would also be + triggered by other reasons, such as a packet is duplicated in the + network. + + Tail Loss Probe (TLP) + =================== + TLP is an algorithm which is used to detect TCP packet loss. For more + details, please refer the `TLP paper`_. + + .. _TLP paper: https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 + + * TcpExtTCPLossProbes + A TLP probe packet is sent. + + * TcpExtTCPLossProbeRecovery + A packet loss is detected and recovered by TLP. examples -======= +======== ping test --------- +--------- Run the ping command against the public dns server 8.8.8.8:: nstatuser@nstat-a:~$ ping 8.8.8.8 -c 1