From: Ben Hutchings <bhutchings@solarflare.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Network Development <netdev@vger.kernel.org>
Subject: Re: LRO/GRO and libpcap packet reordering
Date: Thu, 14 Mar 2013 21:58:14 +0000 [thread overview]
Message-ID: <1363298294.2695.15.camel@bwh-desktop.uk.solarflarecom.com> (raw)
In-Reply-To: <CALCETrXT036Aoaum+uUV_Of0AFdUZ3eq0QjMjxiCJR4n8AZRTQ@mail.gmail.com>
On Thu, 2013-03-14 at 13:37 -0700, Andy Lutomirski wrote:
> (I'm on Ubuntu's 3.5.0-23, but I haven't seen anything that would
> change this behavior in newer kernels.)
>
> I have a myri10ge device that's attached to a port mirror. It runs
> tcpdump. Most of the traffic I'm capturing has another machine
> attached to this switch as an endpoint. That machine is considerably
> faster than the machine doing the capturing.
>
> My captures show nasty artifacts: packets are reodered between a given
> flow and the other direction of the same flow. The nasty case is when
> an ACK shows up before the packet that it's acking. This thoroughly
> screws up Wireshark's TCP sequencing analysis. Turning off LRO and
> GRO fixes it.
>
> Clearly, since this interface doesn't actually have an IP address,
> there's no good reason to keep GRO and LRO on. Nonetheless, it would
> be nice if GRO didn't coalesce packets when there's an intervening
> packing in the other direction on the same flow. Can this be done
> cheaply?
No, it would not be cheap.
You'll probably have to disable GRO, LRO and also RSS (unless you can
configure the RSS hash function to produce the same result for both
directions of a flow).
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
next prev parent reply other threads:[~2013-03-14 21:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-14 20:37 LRO/GRO and libpcap packet reordering Andy Lutomirski
2013-03-14 21:58 ` Ben Hutchings [this message]
2013-03-14 22:45 ` Andy Lutomirski
2013-03-14 22:54 ` Eric Dumazet
2013-03-14 22:58 ` Andy Lutomirski
2013-03-14 23:16 ` Eric Dumazet
2013-03-14 23:21 ` Eric Dumazet
2013-03-14 23:22 ` Andy Lutomirski
2013-03-14 23:01 ` Ben Hutchings
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=1363298294.2695.15.camel@bwh-desktop.uk.solarflarecom.com \
--to=bhutchings@solarflare.com \
--cc=luto@amacapital.net \
--cc=netdev@vger.kernel.org \
/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