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
346 kernel would always add 1 to TcpExtListenDrops. So increase
347 TcpExtListenOverflows would let TcpExtListenDrops increasing at the
348 same time, but TcpExtListenDrops would also increase without
349 TcpExtListenOverflows increasing, e.g. a memory allocation fail would
355 would complete the 3-way handshake. As the accept queue is full, TCP
392 stack would give up the retransmission and update this counter. It
438 good. Kernel would also come into slow path if the "Delayed ack" is
495 and would come to the TIME_WAIT state finally. When kernel has no
496 enough memory to keep the orphan socket, kernel would send an RST to
498 increase 1 to the TcpExtTCPAbortOnMemory. Two conditions would trigger
570 the kernel TCP stack would use SACK, or kernel would use fast
605 The reorder packet is detected by fast recovery. It would only be used
609 order, the receiver would acknowledge multiple times, one for the
611 order packet. Thus the sender would find more ACks than its
633 packet yet, the sender would know packet 4 is out of order. The TCP
693 When a SACK (or DSACK) block is invalid, a corresponding counter would
699 corresponding counter would be updated 3 times. The comment of commit
711 When a DSACK block is invalid, one of these two counters would be
726 15 in skb2 would be moved to skb1. This operation is 'shift'. If a
783 In some scenarios, kernel would avoid sending duplicate ACKs too
786 due to tcp_invalid_ratelimit, kernel would update one of below
788 would only be skipped if the received packet is either a SYN packet or
811 or Time-Wait statuses, the skipped ACK would be counted to
814 would be counted to TcpExtTCPACKSkippedPAWS.
823 The ACK is skipped in Fin-Wait-2 status, the reason would be either
828 The ACK is skipped in Time-Wait status, the reason would be either
836 three scenarios, In some TCP status, the linux TCP stack would also
851 stack receives 3 bytes, the current window size would be 7 even if the
888 ACKed. A Delayed ACK loss might cause this issue, but it would also be
925 but it failed. This counter would be updated in three scenarios: (1)
1360 would try to close these connections, and before they are closed
1363 from the client, so all connection on clients would be stuck on FIN_WAIT_1
1365 10 to /proc/sys/net/ipv4/tcp_max_orphans, so the client system would
1379 would find TcpExtTCPAbortOnMemory is not increased at all. If
1388 fin, and all the client's orphan sockets would timeout on the
1528 on an old kernel, you would see that the connection is succeeded,
1529 because kernel would complete the 3 way handshake and keep the socket
1545 TcpExtListenOverflows and TcpExtListenDrops would be larger, because
1587 dropped packets and increased IpInAddrErrors. As the nc command would
1675 On nstat-a, we blocked the packet from port 9000, or nstat-a would send
1724 We sent two SYN via tcpreplay, both of them would let PAWS check
1732 window. The linux TCP stack would avoid to skip if the packet has