Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
authorDavid S. Miller <davem@davemloft.net>
Mon, 21 Jan 2019 22:41:32 +0000 (14:41 -0800)
committerDavid S. Miller <davem@davemloft.net>
Mon, 21 Jan 2019 22:41:32 +0000 (14:41 -0800)
Completely minor snmp doc conflict.

Signed-off-by: David S. Miller <davem@davemloft.net>
15 files changed:
1  2 
Documentation/networking/snmp_counter.rst
MAINTAINERS
drivers/net/ethernet/intel/igb/igb_main.c
drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
drivers/net/macvlan.c
drivers/net/phy/mdio_bus.c
drivers/net/phy/micrel.c
drivers/net/phy/phy.c
drivers/net/phy/phy_device.c
drivers/net/virtio_net.c
include/linux/phy.h
net/bridge/br_fdb.c
net/ipv4/tcp.c
net/ipv6/ip6_gre.c
net/ipv6/route.c

@@@ -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
diff --cc MAINTAINERS
Simple merge
Simple merge
Simple merge
Simple merge
Simple merge
Simple merge
Simple merge
Simple merge
Simple merge
diff --cc net/ipv4/tcp.c
Simple merge
Simple merge
Simple merge