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 23:01:27 +0000 [thread overview]
Message-ID: <1363302087.2695.25.camel@bwh-desktop.uk.solarflarecom.com> (raw)
In-Reply-To: <CALCETrUidEuaxBeDdDwGb=Dx5iGm1CK-HGWNXRUev5xoR9fnRg@mail.gmail.com>
On Thu, 2013-03-14 at 15:45 -0700, Andy Lutomirski wrote:
> On Thu, Mar 14, 2013 at 2:58 PM, Ben Hutchings
> <bhutchings@solarflare.com> wrote:
> > 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.
> >
>
> Hmm. What if the GRO flow hashing was something like hash(one
> endpoint) ^ hash(the other endpoint)? (NB: I don't really know what
> I'm talking about.)
GRO doesn't use a flow hash; it performs an exact comparison of the
identifying fields. (And only holds aggregated skbs for up to 8 flows
at a time.)
Ben.
> > 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).
> >
>
> RSS was already off. That was the first thing I tried.
>
> --Andy
--
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.
prev parent reply other threads:[~2013-03-14 23:01 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
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 [this message]
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=1363302087.2695.25.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