netdev - Re: ixgbe: Replace LRO with GRO

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090117034510.GA23714@gondor.apana.org.au>
Date:	Sat, 17 Jan 2009 14:45:10 +1100
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	"Tantilov, Emil S" <emil.s.tantilov@...el.com>
Cc:	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"David S. Miller" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: ixgbe: Replace LRO with GRO

On Fri, Jan 16, 2009 at 06:06:18PM -0700, Tantilov, Emil S wrote:
> See attached.

Thanks Emil!

However, it's not very clear who is the sender in this case :)

FTP has a separate data connection, so the sender of the control
connection is not necessarily the sender of the data connection.

In fact, looking at the dump of the data connection it'd appear
that the one you marked as the sender dump is in fact the receiver
for the data connection:

12:07:17.045244 IP (tos 0x8, ttl 64, id 19084, offset 0, flags [DF], proto TCP (6), length 1500) 190.0.15.1.9504 > 190.0.15.3.41206: . 1:1449(1448) ack 1 win 46 <nop,nop,timestamp 199022661 4897363>
12:07:17.045260 IP (tos 0x8, ttl 64, id 15863, offset 0, flags [DF], proto TCP (6), length 52) 190.0.15.3.41206 > 190.0.15.1.9504: ., cksum 0x72a1 (correct), ack 1449 win 69 <nop,nop,timestamp 4897363 199022661>

We can see that because the delta between the data and the ack
is much smaller on this side.

It's also peculiar that there seems to be no GRO aggregation
at all on either side.  Were these dumps taken with it enabled
on both sides? You'll need a patched ethtool to check.

The transfer itself appears to be encountering a lot of packet loss,
which presumably caused a premature end which is why you saw a
missing chunk in the file.

However, it is not very clear what is causing this loss.  BTW,
did you apply the fix b0059b50b70dc3a908bea4ece2f9494a22200018
(gro: Fix page ref count for skbs freed normally) on both sides?
That one is required to make igb or ixgbe work properly.

Another thing to try is to disable GSO/TSO on both sides as that
is complicating the interpretation of the dumps.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html