| Message ID | d653597e-9b1f-4eb7-af36-8d79cc5146b7@esteem.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | Throughtput regression due to [v2,net,2/2] tcp: fix delayed ACKs for MSS boundary condition | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Guessing tree name failed - patch did not apply |
On Fri, Jun 14, 2024 at 9:50 AM Neil Hellfeldt <hellfeldt@esteem.com> wrote: > > Hi, > > So I believe I found a regression due to: > patch: [v2,net,2/2] tcp: fix delayed ACKs for MSS boundary condition > commit: 4720852ed9afb1c5ab84e96135cb5b73d5afde6f > > I recently upgraded our production machines from Ubuntu 16.04 all the > way up to 24.04. > > In the process I noticed that iperf3 was no longer able to get the > throughput that it was able to on 16.04 > I found that Ubuntu 22.04 is when it broke. Then I found that Ubuntu's > kernel version 5.15.0-92 worked > fine and version 5.15.0-93 did not. After that I narrowed it down to the > patch: > > patch: [v2,net,2/2] tcp: fix delayed ACKs for MSS boundary condition > commit: 4720852ed9afb1c5ab84e96135cb5b73d5afde6f > > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > index 06fe1cf645d5a..8afb0950a6979 100644 > --- a/net/ipv4/tcp_input.c > +++ b/net/ipv4/tcp_input.c > @@ -253,6 +253,19 @@ static void tcp_measure_rcv_mss(struct sock *sk, const struct sk_buff *skb) > if (unlikely(len > icsk->icsk_ack.rcv_mss + > MAX_TCP_OPTION_SPACE)) > tcp_gro_dev_warn(sk, skb, len); > + /* If the skb has a len of exactly 1*MSS and has the PSH bit > + * set then it is likely the end of an application write. So > + * more data may not be arriving soon, and yet the data sender > + * may be waiting for an ACK if cwnd-bound or using TX zero > + * copy. So we set ICSK_ACK_PUSHED here so that > + * tcp_cleanup_rbuf() will send an ACK immediately if the app > + * reads all of the data and is not ping-pong. If len > MSS > + * then this logic does not matter (and does not hurt) because > + * tcp_cleanup_rbuf() will always ACK immediately if the app > + * reads data and there is more than an MSS of unACKed data. > + */ > + if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_PSH) > + icsk->icsk_ack.pending |= ICSK_ACK_PUSHED; > } else { > /* Otherwise, we make more careful check taking into account, > * that SACKs block is variable. > > > After I removed the patches I was able to get the expected speeds. I then reverted the patched on most current > version of the kernel for Ubuntu which is 6.8.0-35 and I was able to get the expected speeds again. > > The device unit under test is a embedded device with lwip and built in iperf3 server. It has 100mbit network port. > It is also a low data rate wireless radio. The expected rate for the Ethernet is ~52000Kbps avg with the patch applied > it was getting ~38000Kbps. The expected throughput for wireless is ~328kbps with the patch applied were are getting ~292Kbps. > That a ~27% throughput regression for Ethernet and a ~11% for the wireless. > > command used iperf3 -c 172.18.8.134 -P 1 -i 1 -f m -t 10 -4 -w 64K -R > Iperf version is 3.0.11 from Ubuntu. The newer version of iperf3 3.16 show the correct speeds but shows a saw tooth plot for the wireless. Thanks for the report! AFAICT your email did not specify the direction of data transfer, but I gather that you are talking about a throughput regression when the embedded device is the TCP sender and the Ubuntu machine is the receiver? Can you please gather some traces on the receiver Ubuntu machine, as root, and share the results? Something like: tcpdump -w /root/tcpdump.pcap -n -s 116 -c 1000000 -i $eth_device & nstat -n; (while true; do date; nstat; sleep 0.5; done) > /root/nstat.txt & # run test ... kill %1 kill %2 Ideally it would be great if you could provide those traces for (a) the fast case, and then also (b) the slow case, so we can compare. Thanks! neal
Sorry I included the iperf3 command thinking that was enough to explain the direction but not everyone knows iperf "-R, --reverse run in reverse mode (server sends, client receives)" So in this case the embedded device is the sender. Here are the results Thanks Neil On 6/14/24 09:24, Neal Cardwell wrote: > [You don't often get email from ncardwell@google.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > On Fri, Jun 14, 2024 at 9:50 AM Neil Hellfeldt <hellfeldt@esteem.com> wrote: >> Hi, >> >> So I believe I found a regression due to: >> patch: [v2,net,2/2] tcp: fix delayed ACKs for MSS boundary condition >> commit: 4720852ed9afb1c5ab84e96135cb5b73d5afde6f >> >> I recently upgraded our production machines from Ubuntu 16.04 all the >> way up to 24.04. >> >> In the process I noticed that iperf3 was no longer able to get the >> throughput that it was able to on 16.04 >> I found that Ubuntu 22.04 is when it broke. Then I found that Ubuntu's >> kernel version 5.15.0-92 worked >> fine and version 5.15.0-93 did not. After that I narrowed it down to the >> patch: >> >> patch: [v2,net,2/2] tcp: fix delayed ACKs for MSS boundary condition >> commit: 4720852ed9afb1c5ab84e96135cb5b73d5afde6f >> >> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c >> index 06fe1cf645d5a..8afb0950a6979 100644 >> --- a/net/ipv4/tcp_input.c >> +++ b/net/ipv4/tcp_input.c >> @@ -253,6 +253,19 @@ static void tcp_measure_rcv_mss(struct sock *sk, const struct sk_buff *skb) >> if (unlikely(len > icsk->icsk_ack.rcv_mss + >> MAX_TCP_OPTION_SPACE)) >> tcp_gro_dev_warn(sk, skb, len); >> + /* If the skb has a len of exactly 1*MSS and has the PSH bit >> + * set then it is likely the end of an application write. So >> + * more data may not be arriving soon, and yet the data sender >> + * may be waiting for an ACK if cwnd-bound or using TX zero >> + * copy. So we set ICSK_ACK_PUSHED here so that >> + * tcp_cleanup_rbuf() will send an ACK immediately if the app >> + * reads all of the data and is not ping-pong. If len > MSS >> + * then this logic does not matter (and does not hurt) because >> + * tcp_cleanup_rbuf() will always ACK immediately if the app >> + * reads data and there is more than an MSS of unACKed data. >> + */ >> + if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_PSH) >> + icsk->icsk_ack.pending |= ICSK_ACK_PUSHED; >> } else { >> /* Otherwise, we make more careful check taking into account, >> * that SACKs block is variable. >> >> >> After I removed the patches I was able to get the expected speeds. I then reverted the patched on most current >> version of the kernel for Ubuntu which is 6.8.0-35 and I was able to get the expected speeds again. >> >> The device unit under test is a embedded device with lwip and built in iperf3 server. It has 100mbit network port. >> It is also a low data rate wireless radio. The expected rate for the Ethernet is ~52000Kbps avg with the patch applied >> it was getting ~38000Kbps. The expected throughput for wireless is ~328kbps with the patch applied were are getting ~292Kbps. >> That a ~27% throughput regression for Ethernet and a ~11% for the wireless. >> >> command used iperf3 -c 172.18.8.134 -P 1 -i 1 -f m -t 10 -4 -w 64K -R >> Iperf version is 3.0.11 from Ubuntu. The newer version of iperf3 3.16 show the correct speeds but shows a saw tooth plot for the wireless. > Thanks for the report! > > AFAICT your email did not specify the direction of data transfer, but > I gather that you are talking about a throughput regression when the > embedded device is the TCP sender and the Ubuntu machine is the > receiver? > > Can you please gather some traces on the receiver Ubuntu machine, as > root, and share the results? > > Something like: > > tcpdump -w /root/tcpdump.pcap -n -s 116 -c 1000000 -i $eth_device & > nstat -n; (while true; do date; nstat; sleep 0.5; done) > /root/nstat.txt & > # run test ... > kill %1 > kill %2 > > Ideally it would be great if you could provide those traces for (a) > the fast case, and then also (b) the slow case, so we can compare. > > Thanks! > neal Connecting to host 172.18.8.134, port 5201 Reverse mode, remote host 172.18.8.134 is sending [ 4] local 172.18.32.49 port 59832 connected to 172.18.8.134 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 6.08 MBytes 51.0 Mbits/sec [ 4] 1.00-2.00 sec 6.09 MBytes 51.1 Mbits/sec [ 4] 2.00-3.00 sec 6.09 MBytes 51.1 Mbits/sec [ 4] 3.00-4.00 sec 6.09 MBytes 51.1 Mbits/sec [ 4] 4.00-5.00 sec 6.09 MBytes 51.1 Mbits/sec [ 4] 5.00-6.00 sec 6.09 MBytes 51.1 Mbits/sec [ 4] 6.00-7.00 sec 6.09 MBytes 51.1 Mbits/sec [ 4] 7.00-8.00 sec 6.09 MBytes 51.1 Mbits/sec [ 4] 8.00-9.00 sec 6.09 MBytes 51.1 Mbits/sec [ 4] 9.00-10.00 sec 6.09 MBytes 51.1 Mbits/sec iperf Done. Fri Jun 14 12:03:31 PM PDT 2024 #kernel Fri Jun 14 12:03:31 PM PDT 2024 #kernel IpInReceives 1085 0.0 IpInDelivers 1085 0.0 IpOutRequests 557 0.0 IpOutTransmits 557 0.0 TcpActiveOpens 2 0.0 TcpInSegs 1085 0.0 TcpOutSegs 556 0.0 TcpRetransSegs 1 0.0 TcpExtDelayedACKs 1 0.0 TcpExtTCPPureAcks 2 0.0 TcpExtTCPTimeouts 1 0.0 TcpExtTCPOrigDataSent 4 0.0 TcpExtTCPKeepAlive 1 0.0 TcpExtTCPDelivered 6 0.0 TcpExtTcpTimeoutRehash 1 0.0 IpExtInOctets 1615822 0.0 IpExtOutOctets 22489 0.0 IpExtInNoECTPkts 1084 0.0 Fri Jun 14 12:03:32 PM PDT 2024 #kernel IpInReceives 2211 0.0 IpInDelivers 2211 0.0 IpOutRequests 1106 0.0 IpOutTransmits 1106 0.0 TcpInSegs 2211 0.0 TcpOutSegs 1106 0.0 IpExtInOctets 3316500 0.0 IpExtOutOctets 44200 0.0 IpExtInNoECTPkts 2211 0.0 Fri Jun 14 12:03:32 PM PDT 2024 #kernel IpInReceives 2209 0.0 IpInDelivers 2209 0.0 IpOutRequests 1104 0.0 IpOutTransmits 1104 0.0 TcpInSegs 2209 0.0 TcpOutSegs 1104 0.0 IpExtInOctets 3313500 0.0 IpExtOutOctets 44200 0.0 IpExtInNoECTPkts 2209 0.0 Fri Jun 14 12:03:33 PM PDT 2024 #kernel IpInReceives 2217 0.0 IpInDelivers 2217 0.0 IpOutRequests 1109 0.0 IpOutTransmits 1109 0.0 TcpEstabResets 1 0.0 TcpInSegs 2217 0.0 TcpOutSegs 1109 0.0 TcpExtTCPPureAcks 1 0.0 TcpExtTCPRcvCoalesce 1 0.0 TcpExtTCPKeepAlive 1 0.0 IpExtInOctets 3321092 0.0 IpExtOutOctets 44320 0.0 IpExtInNoECTPkts 2216 0.0 Fri Jun 14 12:03:33 PM PDT 2024 #kernel IpInReceives 2209 0.0 IpInDelivers 2209 0.0 IpOutRequests 1105 0.0 IpOutTransmits 1105 0.0 TcpInSegs 2209 0.0 TcpOutSegs 1105 0.0 IpExtInOctets 3312091 0.0 IpExtOutOctets 44200 0.0 IpExtInNoECTPkts 2209 0.0 Fri Jun 14 12:03:34 PM PDT 2024 #kernel IpInReceives 2209 0.0 IpInDelivers 2209 0.0 IpOutRequests 1104 0.0 IpOutTransmits 1104 0.0 TcpInSegs 2209 0.0 TcpOutSegs 1104 0.0 TcpExtTCPRcvCoalesce 1 0.0 IpExtInOctets 3315000 0.0 IpExtOutOctets 44200 0.0 IpExtInNoECTPkts 2210 0.0 Fri Jun 14 12:03:34 PM PDT 2024 #kernel IpInReceives 2220 0.0 IpInDelivers 2220 0.0 IpOutRequests 1111 0.0 IpOutTransmits 1111 0.0 TcpEstabResets 1 0.0 TcpInSegs 2219 0.0 TcpOutSegs 1111 0.0 UdpInDatagrams 1 0.0 TcpExtTCPHPHits 1 0.0 TcpExtTCPPureAcks 1 0.0 TcpExtTCPHPAcks 2 0.0 TcpExtTCPOrigDataSent 2 0.0 TcpExtTCPKeepAlive 1 0.0 TcpExtTCPDelivered 2 0.0 IpExtInOctets 3321442 0.0 IpExtOutOctets 44608 0.0 IpExtInNoECTPkts 2220 0.0 Fri Jun 14 12:03:35 PM PDT 2024 #kernel IpInReceives 2214 0.0 IpInDelivers 2214 0.0 IpOutRequests 1107 0.0 IpOutTransmits 1107 0.0 TcpInSegs 2214 0.0 TcpOutSegs 1107 0.0 IpExtInOctets 3321000 0.0 IpExtOutOctets 44280 0.0 IpExtInNoECTPkts 2214 0.0 Fri Jun 14 12:03:35 PM PDT 2024 #kernel IpInReceives 2210 0.0 IpInDelivers 2210 0.0 IpOutRequests 1105 0.0 IpOutTransmits 1105 0.0 TcpInSegs 2210 0.0 TcpOutSegs 1105 0.0 IpExtInOctets 3315000 0.0 IpExtOutOctets 44200 0.0 IpExtInNoECTPkts 2210 0.0 Fri Jun 14 12:03:36 PM PDT 2024 #kernel IpInReceives 2219 0.0 IpInDelivers 2219 0.0 IpOutRequests 1110 0.0 IpOutTransmits 1110 0.0 TcpInSegs 2219 0.0 TcpOutSegs 1110 0.0 IpExtInOctets 3330000 0.0 IpExtOutOctets 44360 0.0 IpExtInNoECTPkts 2220 0.0 Fri Jun 14 12:03:36 PM PDT 2024 #kernel IpInReceives 2207 0.0 IpInDelivers 2207 0.0 IpOutRequests 1103 0.0 IpOutTransmits 1103 0.0 TcpInSegs 2207 0.0 TcpOutSegs 1103 0.0 IpExtInOctets 3309000 0.0 IpExtOutOctets 44160 0.0 IpExtInNoECTPkts 2206 0.0 Fri Jun 14 12:03:37 PM PDT 2024 #kernel IpInReceives 2209 0.0 IpInDelivers 2209 0.0 IpOutRequests 1105 0.0 IpOutTransmits 1105 0.0 TcpInSegs 2209 0.0 TcpOutSegs 1105 0.0 IpExtInOctets 3313500 0.0 IpExtOutOctets 44160 0.0 IpExtInNoECTPkts 2209 0.0 Fri Jun 14 12:03:37 PM PDT 2024 #kernel IpInReceives 2217 0.0 IpInDelivers 2217 0.0 IpOutRequests 1109 0.0 IpOutTransmits 1109 0.0 TcpInSegs 2217 0.0 TcpOutSegs 1109 0.0 TcpExtTCPPureAcks 1 0.0 TcpExtTCPKeepAlive 1 0.0 IpExtInOctets 3322552 0.0 IpExtOutOctets 44372 0.0 IpExtInNoECTPkts 2216 0.0 Fri Jun 14 12:03:38 PM PDT 2024 #kernel IpInReceives 2204 0.0 IpInDelivers 2204 0.0 IpOutRequests 1102 0.0 IpOutTransmits 1102 0.0 TcpInSegs 2204 0.0 TcpOutSegs 1102 0.0 IpExtInOctets 3309000 0.0 IpExtOutOctets 44120 0.0 IpExtInNoECTPkts 2206 0.0 Fri Jun 14 12:03:38 PM PDT 2024 #kernel IpInReceives 2210 0.0 IpInDelivers 2210 0.0 IpOutRequests 1106 0.0 IpOutTransmits 1106 0.0 TcpInSegs 2210 0.0 TcpOutSegs 1105 0.0 UdpOutDatagrams 1 0.0 IpExtInOctets 3313500 0.0 IpExtOutOctets 44228 0.0 IpExtInNoECTPkts 2209 0.0 Fri Jun 14 12:03:39 PM PDT 2024 #kernel IpInReceives 2211 0.0 IpInDelivers 2211 0.0 IpOutRequests 1105 0.0 IpOutTransmits 1105 0.0 TcpInSegs 2211 0.0 TcpOutSegs 1105 0.0 IpExtInOctets 3316500 0.0 IpExtOutOctets 44240 0.0 IpExtInNoECTPkts 2211 0.0 Fri Jun 14 12:03:39 PM PDT 2024 #kernel IpInReceives 2214 0.0 IpInDelivers 2214 0.0 IpOutRequests 1109 0.0 IpOutTransmits 1109 0.0 TcpInSegs 2214 0.0 TcpOutSegs 1109 0.0 TcpExtTCPHPHits 1 0.0 TcpExtTCPHPAcks 2 0.0 TcpExtTCPOrigDataSent 2 0.0 TcpExtTCPDelivered 2 0.0 IpExtInOctets 3315276 0.0 IpExtOutOctets 44476 0.0 IpExtInNoECTPkts 2213 0.0 Fri Jun 14 12:03:40 PM PDT 2024 #kernel IpInReceives 2210 0.0 IpInDelivers 2210 0.0 IpOutRequests 1105 0.0 IpOutTransmits 1105 0.0 TcpInSegs 2210 0.0 TcpOutSegs 1105 0.0 IpExtInOctets 3315000 0.0 IpExtOutOctets 44200 0.0 IpExtInNoECTPkts 2210 0.0 Fri Jun 14 12:03:40 PM PDT 2024 #kernel IpInReceives 2209 0.0 IpInDelivers 2209 0.0 IpOutRequests 1104 0.0 IpOutTransmits 1104 0.0 TcpInSegs 2210 0.0 TcpOutSegs 1105 0.0 IpExtInOctets 3315000 0.0 IpExtOutOctets 44200 0.0 IpExtInNoECTPkts 2210 0.0 Fri Jun 14 12:03:41 PM PDT 2024 #kernel IpInReceives 2214 0.0 IpInDelivers 2214 0.0 IpOutRequests 1108 0.0 IpOutTransmits 1108 0.0 TcpInSegs 2213 0.0 TcpOutSegs 1107 0.0 TcpExtTCPPureAcks 2 0.0 TcpExtTCPKeepAlive 2 0.0 IpExtInOctets 3318092 0.0 IpExtOutOctets 44320 0.0 IpExtInNoECTPkts 2214 0.0 Fri Jun 14 12:03:41 PM PDT 2024 #kernel IpInReceives 2212 0.0 IpInDelivers 2212 0.0 IpOutRequests 1109 0.0 IpOutTransmits 1109 0.0 TcpInSegs 2212 0.0 TcpOutSegs 1109 0.0 TcpExtTW 1 0.0 TcpExtTCPPureAcks 2 0.0 TcpExtTCPOrigDataSent 2 0.0 TcpExtTCPKeepAlive 1 0.0 TcpExtTCPDelivered 2 0.0 IpExtInOctets 3313650 0.0 IpExtOutOctets 44380 0.0 IpExtInNoECTPkts 2212 0.0 Fri Jun 14 12:03:42 PM PDT 2024 #kernel IpInReceives 2211 0.0 IpInDelivers 2211 0.0 IpOutRequests 1105 0.0 IpOutTransmits 1105 0.0 TcpInSegs 2211 0.0 TcpOutSegs 1105 0.0 IpExtInOctets 3316500 0.0 IpExtOutOctets 44240 0.0 IpExtInNoECTPkts 2211 0.0 Connecting to host 172.18.8.134, port 5201 Reverse mode, remote host 172.18.8.134 is sending [ 4] local 172.18.32.49 port 58688 connected to 172.18.8.134 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 4.66 MBytes 39.1 Mbits/sec [ 4] 1.00-2.00 sec 4.66 MBytes 39.1 Mbits/sec [ 4] 2.00-3.00 sec 4.65 MBytes 39.0 Mbits/sec [ 4] 3.00-4.00 sec 4.65 MBytes 39.0 Mbits/sec [ 4] 4.00-5.00 sec 4.66 MBytes 39.1 Mbits/sec [ 4] 5.00-6.00 sec 4.65 MBytes 39.0 Mbits/sec [ 4] 6.00-7.00 sec 4.66 MBytes 39.1 Mbits/sec [ 4] 7.00-8.00 sec 4.65 MBytes 39.0 Mbits/sec [ 4] 8.00-9.00 sec 4.66 MBytes 39.1 Mbits/sec [ 4] 9.00-10.00 sec 4.65 MBytes 39.0 Mbits/sec iperf Done. Fri Jun 14 12:00:17 PM PDT 2024 #kernel Fri Jun 14 12:00:17 PM PDT 2024 #kernel IpInReceives 820 0.0 IpInDelivers 820 0.0 IpOutRequests 821 0.0 IpOutTransmits 821 0.0 TcpActiveOpens 2 0.0 TcpInSegs 816 0.0 TcpOutSegs 820 0.0 TcpRetransSegs 1 0.0 UdpInDatagrams 6 0.0 TcpExtDelayedACKs 1 0.0 TcpExtTCPPureAcks 2 0.0 TcpExtTCPTimeouts 1 0.0 TcpExtTCPOrigDataSent 4 0.0 TcpExtTCPDelivered 6 0.0 TcpExtTcpTimeoutRehash 1 0.0 IpExtInMcastPkts 2 0.0 IpExtInOctets 1214852 0.0 IpExtOutOctets 33009 0.0 IpExtInMcastOctets 463 0.0 IpExtInNoECTPkts 820 0.0 Fri Jun 14 12:00:18 PM PDT 2024 #kernel IpInReceives 1689 0.0 IpInDelivers 1689 0.0 IpOutRequests 1689 0.0 IpOutTransmits 1689 0.0 TcpInSegs 1689 0.0 TcpOutSegs 1689 0.0 TcpExtTCPHPHits 1 0.0 TcpExtTCPHPAcks 2 0.0 TcpExtTCPOrigDataSent 2 0.0 TcpExtTCPDelivered 2 0.0 IpExtInOctets 2527776 0.0 IpExtOutOctets 67716 0.0 IpExtInNoECTPkts 1688 0.0 Fri Jun 14 12:00:18 PM PDT 2024 #kernel IpInReceives 1687 0.0 IpInDelivers 1687 0.0 IpOutRequests 1687 0.0 IpOutTransmits 1687 0.0 TcpInSegs 1687 0.0 TcpOutSegs 1687 0.0 IpExtInOctets 2530500 0.0 IpExtOutOctets 67480 0.0 IpExtInNoECTPkts 1687 0.0 Fri Jun 14 12:00:19 PM PDT 2024 #kernel IpInReceives 1690 0.0 IpInDelivers 1690 0.0 IpOutRequests 1690 0.0 IpOutTransmits 1690 0.0 TcpInSegs 1690 0.0 TcpOutSegs 1690 0.0 IpExtInOctets 2535000 0.0 IpExtOutOctets 67600 0.0 IpExtInNoECTPkts 1690 0.0 Fri Jun 14 12:00:19 PM PDT 2024 #kernel IpInReceives 1690 0.0 IpInDelivers 1690 0.0 IpOutRequests 1686 0.0 IpOutTransmits 1686 0.0 TcpInSegs 1686 0.0 TcpOutSegs 1686 0.0 UdpInDatagrams 6 0.0 IpExtInMcastPkts 2 0.0 IpExtInOctets 2530030 0.0 IpExtOutOctets 67440 0.0 IpExtInMcastOctets 463 0.0 IpExtInNoECTPkts 1690 0.0 Fri Jun 14 12:00:20 PM PDT 2024 #kernel IpInReceives 1686 0.0 IpInDelivers 1686 0.0 IpOutRequests 1686 0.0 IpOutTransmits 1686 0.0 TcpInSegs 1686 0.0 TcpOutSegs 1686 0.0 IpExtInOctets 2529000 0.0 IpExtOutOctets 67440 0.0 IpExtInNoECTPkts 1686 0.0 Fri Jun 14 12:00:20 PM PDT 2024 #kernel IpInReceives 1681 0.0 IpInDelivers 1681 0.0 IpOutRequests 1681 0.0 IpOutTransmits 1681 0.0 TcpInSegs 1681 0.0 TcpOutSegs 1681 0.0 IpExtInOctets 2523000 0.0 IpExtOutOctets 67280 0.0 IpExtInNoECTPkts 1682 0.0 Fri Jun 14 12:00:21 PM PDT 2024 #kernel IpInReceives 1684 0.0 IpInDelivers 1684 0.0 IpOutRequests 1683 0.0 IpOutTransmits 1683 0.0 TcpInSegs 1684 0.0 TcpOutSegs 1683 0.0 TcpExtTCPRcvCoalesce 1 0.0 IpExtInOctets 2526000 0.0 IpExtOutOctets 67320 0.0 IpExtInNoECTPkts 1684 0.0 Fri Jun 14 12:00:21 PM PDT 2024 #kernel IpInReceives 1687 0.0 IpInDelivers 1687 0.0 IpOutRequests 1687 0.0 IpOutTransmits 1687 0.0 TcpInSegs 1687 0.0 TcpOutSegs 1687 0.0 IpExtInOctets 2529000 0.0 IpExtOutOctets 67440 0.0 IpExtInNoECTPkts 1686 0.0 Fri Jun 14 12:00:22 PM PDT 2024 #kernel IpInReceives 1685 0.0 IpInDelivers 1685 0.0 IpOutRequests 1685 0.0 IpOutTransmits 1685 0.0 TcpInSegs 1685 0.0 TcpOutSegs 1685 0.0 IpExtInOctets 2527500 0.0 IpExtOutOctets 67400 0.0 IpExtInNoECTPkts 1685 0.0 Fri Jun 14 12:00:22 PM PDT 2024 #kernel IpInReceives 1690 0.0 IpInDelivers 1690 0.0 IpOutRequests 1690 0.0 IpOutTransmits 1690 0.0 TcpInSegs 1690 0.0 TcpOutSegs 1690 0.0 IpExtInOctets 2535000 0.0 IpExtOutOctets 67600 0.0 IpExtInNoECTPkts 1690 0.0 Fri Jun 14 12:00:23 PM PDT 2024 #kernel IpInReceives 1692 0.0 IpInDelivers 1692 0.0 IpOutRequests 1692 0.0 IpOutTransmits 1692 0.0 TcpInSegs 1692 0.0 TcpOutSegs 1692 0.0 TcpExtTCPHPHits 1 0.0 TcpExtTCPHPAcks 2 0.0 TcpExtTCPOrigDataSent 2 0.0 TcpExtTCPDelivered 2 0.0 IpExtInOctets 2533776 0.0 IpExtOutOctets 67836 0.0 IpExtInNoECTPkts 1692 0.0 Fri Jun 14 12:00:23 PM PDT 2024 #kernel IpInReceives 1685 0.0 IpInDelivers 1685 0.0 IpOutRequests 1685 0.0 IpOutTransmits 1685 0.0 TcpInSegs 1685 0.0 TcpOutSegs 1685 0.0 IpExtInOctets 2527500 0.0 IpExtOutOctets 67400 0.0 IpExtInNoECTPkts 1685 0.0 Fri Jun 14 12:00:24 PM PDT 2024 #kernel IpInReceives 1689 0.0 IpInDelivers 1689 0.0 IpOutRequests 1689 0.0 IpOutTransmits 1689 0.0 TcpInSegs 1689 0.0 TcpOutSegs 1689 0.0 IpExtInOctets 2533500 0.0 IpExtOutOctets 67560 0.0 IpExtInNoECTPkts 1689 0.0 Fri Jun 14 12:00:24 PM PDT 2024 #kernel IpInReceives 1688 0.0 IpInDelivers 1688 0.0 IpOutRequests 1688 0.0 IpOutTransmits 1688 0.0 TcpInSegs 1688 0.0 TcpOutSegs 1688 0.0 IpExtInOctets 2532000 0.0 IpExtOutOctets 67520 0.0 IpExtInNoECTPkts 1688 0.0 Fri Jun 14 12:00:25 PM PDT 2024 #kernel IpInReceives 1689 0.0 IpInDelivers 1689 0.0 IpOutRequests 1689 0.0 IpOutTransmits 1689 0.0 TcpInSegs 1689 0.0 TcpOutSegs 1689 0.0 IpExtInOctets 2533500 0.0 IpExtOutOctets 67560 0.0 IpExtInNoECTPkts 1689 0.0 Fri Jun 14 12:00:25 PM PDT 2024 #kernel IpInReceives 1686 0.0 IpInDelivers 1686 0.0 IpOutRequests 1686 0.0 IpOutTransmits 1686 0.0 TcpInSegs 1686 0.0 TcpOutSegs 1686 0.0 UdpOutDatagrams 1 0.0 IpExtInOctets 2529000 0.0 IpExtOutOctets 67508 0.0 IpExtInNoECTPkts 1686 0.0 Fri Jun 14 12:00:26 PM PDT 2024 #kernel IpInReceives 1687 0.0 IpInDelivers 1687 0.0 IpOutRequests 1687 0.0 IpOutTransmits 1687 0.0 TcpInSegs 1687 0.0 TcpOutSegs 1686 0.0 TcpExtTCPRcvCoalesce 1 0.0 IpExtInOctets 2530500 0.0 IpExtOutOctets 67440 0.0 IpExtInNoECTPkts 1687 0.0 Fri Jun 14 12:00:26 PM PDT 2024 #kernel IpInReceives 1688 0.0 IpInDelivers 1688 0.0 IpOutRequests 1688 0.0 IpOutTransmits 1688 0.0 TcpInSegs 1688 0.0 TcpOutSegs 1688 0.0 IpExtInOctets 2532000 0.0 IpExtOutOctets 67520 0.0 IpExtInNoECTPkts 1688 0.0 Fri Jun 14 12:00:27 PM PDT 2024 #kernel IpInReceives 1691 0.0 IpInDelivers 1691 0.0 IpOutRequests 1691 0.0 IpOutTransmits 1691 0.0 TcpInSegs 1691 0.0 TcpOutSegs 1691 0.0 IpExtInOctets 2535091 0.0 IpExtOutOctets 67640 0.0 IpExtInNoECTPkts 1691 0.0 Fri Jun 14 12:00:27 PM PDT 2024 #kernel IpInReceives 1687 0.0 IpInDelivers 1687 0.0 IpOutRequests 1687 0.0 IpOutTransmits 1687 0.0 TcpInSegs 1687 0.0 TcpOutSegs 1687 0.0 IpExtInOctets 2530500 0.0 IpExtOutOctets 67480 0.0 IpExtInNoECTPkts 1687 0.0 Fri Jun 14 12:00:28 PM PDT 2024 #kernel IpInReceives 1693 0.0 IpInDelivers 1693 0.0 IpOutRequests 1693 0.0 IpOutTransmits 1693 0.0 TcpInSegs 1693 0.0 TcpOutSegs 1693 0.0 TcpExtTCPHPHits 1 0.0 TcpExtTCPHPAcks 2 0.0 TcpExtTCPOrigDataSent 2 0.0 TcpExtTCPDelivered 2 0.0 IpExtInOctets 2535276 0.0 IpExtOutOctets 67876 0.0 IpExtInNoECTPkts 1693 0.0
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 06fe1cf645d5a..8afb0950a6979 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -253,6 +253,19 @@ static void tcp_measure_rcv_mss(struct sock *sk, const struct sk_buff *skb) if (unlikely(len > icsk->icsk_ack.rcv_mss + MAX_TCP_OPTION_SPACE)) tcp_gro_dev_warn(sk, skb, len); + /* If the skb has a len of exactly 1*MSS and has the PSH bit + * set then it is likely the end of an application write. So + * more data may not be arriving soon, and yet the data sender + * may be waiting for an ACK if cwnd-bound or using TX zero + * copy. So we set ICSK_ACK_PUSHED here so that + * tcp_cleanup_rbuf() will send an ACK immediately if the app + * reads all of the data and is not ping-pong. If len > MSS + * then this logic does not matter (and does not hurt) because + * tcp_cleanup_rbuf() will always ACK immediately if the app + * reads data and there is more than an MSS of unACKed data. + */ + if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_PSH) + icsk->icsk_ack.pending |= ICSK_ACK_PUSHED; } else { /* Otherwise, we make more careful check taking into account, * that SACKs block is variable.