Lines Matching full:would

44 multicast packets, and would always be updated together with
137 would be increased even if the ICMP packet has an invalid type. The
139 IcmpOutMsgs would still be updated if the IP header is constructed by
207 IcmpMsgOutType8 would increase 1. And if kernel gets an ICMP Echo Reply
208 packet, IcmpMsgInType0 would increase 1.
215 IcmpInMsgs would be updated but none of IcmpMsgInType[N] would be updated.
225 counters would be updated. The receiving packet path use IcmpInErrors
227 is increased, IcmpInErrors would always be increased too.
263 packets would be delivered to the TCP layer, but the TCP layer will discard
266 counter would only increase 1.
277 GSO, so if a packet would be split to 2 by GSO, TcpOutSegs will
304 enabled, lots of packets would be merged by GRO, these packets
348 kernel would always add 1 to TcpExtListenDrops. So increase
349 TcpExtListenOverflows would let TcpExtListenDrops increasing at the
350 same time, but TcpExtListenDrops would also increase without
351 TcpExtListenOverflows increasing, e.g. a memory allocation fail would
357 would complete the 3-way handshake. As the accept queue is full, TCP
394 stack would give up the retransmission and update this counter. It
440 good. Kernel would also come into slow path if the "Delayed ack" is
497 and would come to the TIME_WAIT state finally. When kernel has no
498 enough memory to keep the orphan socket, kernel would send an RST to
500 increase 1 to the TcpExtTCPAbortOnMemory. Two conditions would trigger
572 the kernel TCP stack would use SACK, or kernel would use fast
607 The reorder packet is detected by fast recovery. It would only be used
611 order, the receiver would acknowledge multiple times, one for the
613 order packet. Thus the sender would find more ACks than its
635 packet yet, the sender would know packet 4 is out of order. The TCP
695 When a SACK (or DSACK) block is invalid, a corresponding counter would
701 corresponding counter would be updated 3 times. The comment of the
715 When a DSACK block is invalid, one of these two counters would be
730 15 in skb2 would be moved to skb1. This operation is 'shift'. If a
787 In some scenarios, kernel would avoid sending duplicate ACKs too
790 due to tcp_invalid_ratelimit, kernel would update one of below
792 would only be skipped if the received packet is either a SYN packet or
815 or Time-Wait statuses, the skipped ACK would be counted to
818 would be counted to TcpExtTCPACKSkippedPAWS.
827 The ACK is skipped in Fin-Wait-2 status, the reason would be either
832 Tha ACK is skipped in Time-Wait status, the reason would be either
840 three scenarios, In some TCP status, the linux TCP stack would also
855 stack receives 3 bytes, the current window size would be 7 even if the
892 ACKed. A Delayed ACK loss might cause this issue, but it would also be
929 but it failed. This counter would be updated in three scenarios: (1)
1364 would try to close these connections, and before they are closed
1367 from the client, so all connection on clients would be stuck on FIN_WAIT_1
1369 10 to /proc/sys/net/ipv4/tcp_max_orphans, so the client system would
1383 would find TcpExtTCPAbortOnMemory is not increased at all. If
1392 fin, and all the client's orphan sockets would timeout on the
1532 on an old kernel, you would see that the connection is succeeded,
1533 because kernel would complete the 3 way handshake and keep the socket
1549 TcpExtListenOverflows and TcpExtListenDrops would be larger, because
1591 dropped packets and increased IpInAddrErrors. As the nc command would
1679 On nstat-a, we blocked the packet from port 9000, or nstat-a would send
1728 We sent two SYN via tcpreplay, both of them would let PAWS check
1736 window. The linux TCP stack would avoid to skip if the packet has