From: arno@natisbad.org (Arnaud Ebalard)
To: linux-arm-kernel@lists.infradead.org
Subject: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s
Date: Tue, 12 Nov 2013 08:56:25 +0100 [thread overview]
Message-ID: <87y54u59zq.fsf@natisbad.org> (raw)
In-Reply-To: <slrnl83jr5.49f.xiyou.wangcong@linux-6brj.site> (Cong Wang's message of "Tue, 12 Nov 2013 06:48:59 +0000 (UTC)")
Hi,
Thanks for the pointer. See below.
Cong Wang <xiyou.wangcong@gmail.com> writes:
> On Sun, 10 Nov 2013 at 13:53 GMT, Arnaud Ebalard <arno@natisbad.org> wrote:
>> Hi,
>>
>> I decided to upgrade the kernel on one of my ReadyNAS 102 from 3.11.1 to
>> 3.11.7. The device is based on Marvell Armada 370 SoC and uses mvneta
>> driver. Mine runs Debian armel unstable but I can confirm the issue also
>> happens on a debian harmhf unstable.
>>
> [...]
>>
>> Then, knowing that, I started a git bisect session on stable tree to end
>> up with the following suspects. I failed to go any further to a single
>> commit, due to crashes, but I could recompile a kernel w/ debug info and
>> report what I get if neeeded.
>>
>> commit dc0791aee672 tcp: do not forget FIN in tcp_shifted_skb() [bad]
>> commit 18ddf5127c9f tcp: must unclone packets before mangling them
>> commit 80bd5d8968d8 tcp: TSQ can use a dynamic limit
>> commit dbeb18b22197 tcp: TSO packets automatic sizing
>> commit 50704410d014 Linux 3.11.6 [good]
>>
>
> This regression is probably introduced the last TSQ commit, Eric has a patch
> for mvneta in the other thread:
>
> http://article.gmane.org/gmane.linux.network/290359
I had some offline (*) discussions w/ Eric and did some test w/ the patches
he sent. It does not fix the regression I see. It would be nice if someone
w/ the hardware and more knowledge of mvneta driver could reproduce the
issue and spend some time on it.
That been said, even if the driver is most probably not the only one to
blame here (considering the result of bisect and current thread on
netdev), I never managed to get the performance I have on my ReadyNAS
Duo v2 (i.e. 108MB/s for a file served by an Apache) with a mvneta-based
platform (RN102, RN104 or RN2120). Understanding why is on an already a
long todo list.
Cheers,
a+
(*): for some reasons, my messages to netdev and stable are not published
even though I can interact w/ {majordomo,autoanswer}@vger.kernel.org. I
poked postmaster@ bug got no reply yet.
WARNING: multiple messages have this Message-ID (diff)
From: arno@natisbad.org (Arnaud Ebalard)
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
stable@vger.kernel.org, edumazet@google.com
Subject: Re: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s
Date: Tue, 12 Nov 2013 08:56:25 +0100 [thread overview]
Message-ID: <87y54u59zq.fsf@natisbad.org> (raw)
In-Reply-To: <slrnl83jr5.49f.xiyou.wangcong@linux-6brj.site> (Cong Wang's message of "Tue, 12 Nov 2013 06:48:59 +0000 (UTC)")
Hi,
Thanks for the pointer. See below.
Cong Wang <xiyou.wangcong@gmail.com> writes:
> On Sun, 10 Nov 2013 at 13:53 GMT, Arnaud Ebalard <arno@natisbad.org> wrote:
>> Hi,
>>
>> I decided to upgrade the kernel on one of my ReadyNAS 102 from 3.11.1 to
>> 3.11.7. The device is based on Marvell Armada 370 SoC and uses mvneta
>> driver. Mine runs Debian armel unstable but I can confirm the issue also
>> happens on a debian harmhf unstable.
>>
> [...]
>>
>> Then, knowing that, I started a git bisect session on stable tree to end
>> up with the following suspects. I failed to go any further to a single
>> commit, due to crashes, but I could recompile a kernel w/ debug info and
>> report what I get if neeeded.
>>
>> commit dc0791aee672 tcp: do not forget FIN in tcp_shifted_skb() [bad]
>> commit 18ddf5127c9f tcp: must unclone packets before mangling them
>> commit 80bd5d8968d8 tcp: TSQ can use a dynamic limit
>> commit dbeb18b22197 tcp: TSO packets automatic sizing
>> commit 50704410d014 Linux 3.11.6 [good]
>>
>
> This regression is probably introduced the last TSQ commit, Eric has a patch
> for mvneta in the other thread:
>
> http://article.gmane.org/gmane.linux.network/290359
I had some offline (*) discussions w/ Eric and did some test w/ the patches
he sent. It does not fix the regression I see. It would be nice if someone
w/ the hardware and more knowledge of mvneta driver could reproduce the
issue and spend some time on it.
That been said, even if the driver is most probably not the only one to
blame here (considering the result of bisect and current thread on
netdev), I never managed to get the performance I have on my ReadyNAS
Duo v2 (i.e. 108MB/s for a file served by an Apache) with a mvneta-based
platform (RN102, RN104 or RN2120). Understanding why is on an already a
long todo list.
Cheers,
a+
(*): for some reasons, my messages to netdev and stable are not published
even though I can interact w/ {majordomo,autoanswer}@vger.kernel.org. I
poked postmaster@ bug got no reply yet.
next prev parent reply other threads:[~2013-11-12 7:56 UTC|newest]
Thread overview: 121+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-10 13:53 [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s Arnaud Ebalard
2013-11-10 13:53 ` Arnaud Ebalard
2013-11-12 6:48 ` Cong Wang
2013-11-12 6:48 ` Cong Wang
2013-11-12 7:56 ` Arnaud Ebalard [this message]
2013-11-12 7:56 ` Arnaud Ebalard
2013-11-12 8:36 ` Willy Tarreau
2013-11-12 8:36 ` Willy Tarreau
2013-11-12 9:14 ` Arnaud Ebalard
2013-11-12 9:14 ` Arnaud Ebalard
2013-11-12 10:01 ` Willy Tarreau
2013-11-12 10:01 ` Willy Tarreau
2013-11-12 15:34 ` Arnaud Ebalard
2013-11-12 15:34 ` Arnaud Ebalard
2013-11-13 7:22 ` Willy Tarreau
2013-11-13 7:22 ` Willy Tarreau
2013-11-17 14:19 ` Willy Tarreau
2013-11-17 14:19 ` Willy Tarreau
2013-11-17 17:41 ` Eric Dumazet
2013-11-17 17:41 ` Eric Dumazet
2013-11-19 6:44 ` Arnaud Ebalard
2013-11-19 6:44 ` Arnaud Ebalard
2013-11-19 13:53 ` Eric Dumazet
2013-11-19 13:53 ` Eric Dumazet
2013-11-19 17:43 ` Willy Tarreau
2013-11-19 17:43 ` Willy Tarreau
2013-11-19 18:31 ` Eric Dumazet
2013-11-19 18:31 ` Eric Dumazet
2013-11-19 18:41 ` Willy Tarreau
2013-11-19 18:41 ` Willy Tarreau
2013-11-19 23:53 ` Arnaud Ebalard
2013-11-19 23:53 ` Arnaud Ebalard
2013-11-20 0:08 ` Eric Dumazet
2013-11-20 0:08 ` Eric Dumazet
2013-11-20 0:35 ` Willy Tarreau
2013-11-20 0:35 ` Willy Tarreau
2013-11-20 0:43 ` Eric Dumazet
2013-11-20 0:43 ` Eric Dumazet
2013-11-20 0:52 ` Willy Tarreau
2013-11-20 0:52 ` Willy Tarreau
2013-11-20 8:50 ` Thomas Petazzoni
2013-11-20 8:50 ` Thomas Petazzoni
2013-11-20 19:21 ` Arnaud Ebalard
2013-11-20 19:11 ` Willy Tarreau
2013-11-20 19:11 ` Willy Tarreau
2013-11-20 19:26 ` Arnaud Ebalard
2013-11-20 19:26 ` Arnaud Ebalard
2013-11-20 21:28 ` Arnaud Ebalard
2013-11-20 21:28 ` Arnaud Ebalard
2013-11-20 21:54 ` Willy Tarreau
2013-11-20 21:54 ` Willy Tarreau
2013-11-21 0:44 ` Willy Tarreau
2013-11-21 0:44 ` Willy Tarreau
2013-11-21 18:38 ` ARM network performance and dma_mask (was: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s) Willy Tarreau
2013-11-21 19:04 ` Thomas Petazzoni
2013-11-21 19:04 ` Thomas Petazzoni
2013-11-21 21:51 ` ARM network performance and dma_mask (was: [BUG, REGRESSION?] 3.11.6+, 3.12: " Willy Tarreau
2013-11-21 21:51 ` ARM network performance and dma_mask (was: [BUG,REGRESSION?] 3.11.6+,3.12: " Willy Tarreau
2013-11-21 22:01 ` ARM network performance and dma_mask Rob Herring
2013-11-21 22:01 ` Rob Herring
2013-11-21 22:13 ` Willy Tarreau
2013-11-21 22:13 ` Willy Tarreau
2013-11-21 21:51 ` [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s Arnaud Ebalard
2013-11-21 21:51 ` Arnaud Ebalard
2013-11-21 21:52 ` Willy Tarreau
2013-11-21 21:52 ` Willy Tarreau
2013-11-21 22:00 ` Eric Dumazet
2013-11-21 22:00 ` Eric Dumazet
2013-11-21 22:55 ` Arnaud Ebalard
2013-11-21 22:55 ` Arnaud Ebalard
2013-11-21 23:23 ` Rick Jones
2013-11-21 23:23 ` Rick Jones
2013-11-20 17:12 ` Willy Tarreau
2013-11-20 17:12 ` Willy Tarreau
2013-11-20 17:30 ` Eric Dumazet
2013-11-20 17:30 ` Eric Dumazet
2013-11-20 17:38 ` Willy Tarreau
2013-11-20 17:38 ` Willy Tarreau
2013-11-20 18:52 ` David Miller
2013-11-20 18:52 ` David Miller
2013-11-20 17:34 ` Willy Tarreau
2013-11-20 17:34 ` Willy Tarreau
2013-11-20 17:40 ` Eric Dumazet
2013-11-20 17:40 ` Eric Dumazet
2013-11-20 18:15 ` Willy Tarreau
2013-11-20 18:15 ` Willy Tarreau
2013-11-20 18:21 ` Eric Dumazet
2013-11-20 18:21 ` Eric Dumazet
2013-11-20 18:29 ` Willy Tarreau
2013-11-20 18:29 ` Willy Tarreau
2013-11-20 19:22 ` Arnaud Ebalard
2013-11-20 19:22 ` Arnaud Ebalard
2013-11-18 10:09 ` David Laight
2013-11-18 10:09 ` David Laight
2013-11-18 10:52 ` Willy Tarreau
2013-11-18 10:52 ` Willy Tarreau
2013-11-18 10:26 ` Thomas Petazzoni
2013-11-18 10:26 ` Thomas Petazzoni
2013-11-18 10:44 ` Simon Guinot
2013-11-18 10:44 ` Simon Guinot
2013-11-18 16:54 ` Stephen Hemminger
2013-11-18 16:54 ` Stephen Hemminger
2013-11-18 17:13 ` Eric Dumazet
2013-11-18 17:13 ` Eric Dumazet
2013-11-18 10:51 ` Willy Tarreau
2013-11-18 10:51 ` Willy Tarreau
2013-11-18 17:58 ` Florian Fainelli
2013-11-18 17:58 ` Florian Fainelli
2013-11-12 14:39 ` [PATCH] tcp: tsq: restore minimal amount of queueing Eric Dumazet
2013-11-12 15:24 ` Sujith Manoharan
2013-11-13 14:06 ` Eric Dumazet
2013-11-13 14:32 ` [PATCH v2] " Eric Dumazet
2013-11-13 21:18 ` Arnaud Ebalard
2013-11-13 21:59 ` Holger Hoffstaette
2013-11-13 23:40 ` Eric Dumazet
2013-11-13 23:52 ` Holger Hoffstaette
2013-11-17 23:15 ` Francois Romieu
2013-11-18 16:26 ` Holger Hoffstätte
2013-11-18 16:47 ` Eric Dumazet
2013-11-13 22:41 ` Eric Dumazet
2013-11-14 21:26 ` David Miller
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=87y54u59zq.fsf@natisbad.org \
--to=arno@natisbad.org \
--cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.