Message-ID: <20190117122713.217bbb58@canb.auug.org.au>
Date:   Thu, 17 Jan 2019 12:27:13 +1100
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     David Miller <davem@...emloft.net>,
        Networking <netdev@...r.kernel.org>
Cc:     Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        yupeng <yupeng0921@...il.com>,
        Randy Dunlap <rdunlap@...radead.org>
Subject: linux-next: manual merge of the net-next tree with the net tree

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  Documentation/networking/snmp_counter.rst

between commit:

  a6c7c7aac2de ("net: add document for several snmp counters")

from the net tree and commit:

  ae5220c67218 ("networking: Documentation: fix snmp_counters.rst Sphinx warnings")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/networking/snmp_counter.rst
index fe8f741193be,486ab33acc3a..000000000000
--- a/Documentation/networking/snmp_counter.rst
+++ b/Documentation/networking/snmp_counter.rst
@@@ -336,27 -364,8 +364,27 @@@ 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::
@@@ -582,7 -612,8 +630,8 @@@ The TCP stack receives an out of order 
  DSACK to the sender.
  
  * TcpExtTCPDSACKRecv
+ 
 -The TCP stack receives a DSACK, which indicate an acknowledged
 +The TCP stack receives a DSACK, which indicates an acknowledged
  duplicate packet is received.
  
  * TcpExtTCPDSACKOfoRecv
@@@ -589,59 -621,10 +639,60 @@@
  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.
  
@@@ -728,66 -721,12 +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@...at-a:~$ ping 8.8.8.8 -c 1

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists