netdev - [PATCH][net-next] LRO: improve aggregation in case of zero TSecr packets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <200908270208.31581.opurdila@ixiacom.com>
Date:	Thu, 27 Aug 2009 02:08:31 +0300
From:	Octavian Purdila <opurdila@...acom.com>
To:	"Jan-Bernd Themann" <themann@...ibm.com>
Cc:	Christoph Raisch <raisch@...ibm.com>,
	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Subject: [PATCH][net-next] LRO: improve aggregation in case of zero TSecr packets

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@...acom.com>
---
 net/ipv4/inet_lro.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

View attachment "d943fa4bd69b5ff21505eb6187120fe60868b5f9.diff" of type "text/x-patch" (475 bytes)