From: Octavian Purdila <opurdila@ixiacom.com>
To: "Jan-Bernd Themann" <themann@de.ibm.com>
Cc: Christoph Raisch <raisch@de.ibm.com>,
Eric Dumazet <eric.dumazet@gmail.com>,
netdev@vger.kernel.org
Subject: [PATCH][net-next] LRO: improve aggregation in case of zero TSecr packets
Date: Thu, 27 Aug 2009 02:08:31 +0300 [thread overview]
Message-ID: <200908270208.31581.opurdila@ixiacom.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]
This fixes a temporary performance issue we noticed in back to back
TSO - LRO tests when such tests are run within five minutes after
boot.
The TSval field of TCP packets is filled in based on the current
jiffie, which is initialized at -300*HZ. That means that in 5 minutes
after reboot it will wrap to zero.
While the jiffie value is 0 on the LRO side, TCP packets will be
send out with TSVal zero as well. The TSO side will respond with
packets in which TSecr is set to zero.
At this point LRO will avoid aggregating the packets, suddenly
putting a lot of pressure on the stack which will result in drops and
retransmission for a short while.
There are cases where aggregating zero TSecr is better and cases in
which is not:
1. non zero TSecr packets, zero TSecr packet
Better not to aggregate, otherwise we miss a valid TSecr.
2. zero TSecr packets (amplified by TSO)
Better to aggregate.
3. zero TSecr packet, non zero TSecr packets
OK to aggregate.
4. non zero TSecr packets, zero TSecr packets, non zero TSecr packet
OK to aggregate, but not a big overhead if we aggregate in 2
segments instead of one.
This patch allows aggregation for cases 2 and 3 as well as aggregation
in 2 segments for case 4, while denying aggregation in case 1.
Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
---
net/ipv4/inet_lro.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
[-- Attachment #2: d943fa4bd69b5ff21505eb6187120fe60868b5f9.diff --]
[-- Type: text/x-patch, Size: 474 bytes --]
diff --git a/net/ipv4/inet_lro.c b/net/ipv4/inet_lro.c
index 6a667da..d16c9d5 100644
--- a/net/ipv4/inet_lro.c
+++ b/net/ipv4/inet_lro.c
@@ -90,9 +90,9 @@ static int lro_tcp_ip_check(struct iphdr *iph, struct tcphdr *tcph,
ntohl(*topt)))
return -1;
- /* timestamp reply should not be zero */
+ /* aggregate if we are sure we won't miss a valid TSecr */
topt++;
- if (*topt == 0)
+ if (*topt == 0 && lro_desc->tcp_rcv_tsecr != 0)
return -1;
}
next reply other threads:[~2009-08-26 23:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-26 23:08 Octavian Purdila [this message]
2009-08-31 5:11 ` [PATCH][net-next] LRO: improve aggregation in case of zero TSecr packets David Miller
2009-08-31 17:15 ` Octavian Purdila
2009-09-25 21:33 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200908270208.31581.opurdila@ixiacom.com \
--to=opurdila@ixiacom.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=raisch@de.ibm.com \
--cc=themann@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox