[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <948e8dc00b4a4b6894111a17eaf89b03@HKXPR30MB0039.064d.mgd.msft.net>
Date: Mon, 9 Nov 2015 03:31:15 +0000
From: Dexuan Cui <decui@...rosoft.com>
To: David Miller <davem@...emloft.net>
CC: "eric.dumazet@...il.com" <eric.dumazet@...il.com>,
"dsa@...ulusnetworks.com" <dsa@...ulusnetworks.com>,
Simon Xiao <sixiao@...rosoft.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Haiyang Zhang <haiyangz@...rosoft.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>
Subject: RE: linux-next network throughput performance regression
> From: David Miller [mailto:davem@...emloft.net]
> Sent: Monday, November 9, 2015 11:24
> ...
> > Thanks, David!
> > I understand 1 TX queue is the bottleneck (however in Simon's
> > test, TX=1 => 36.7Gb/s, TX=8 => 37.7 Gb/s, so it looks the TX=1 bottleneck
> > is not so obvious).
> > I'm just wondering how the bottleneck became much narrower with
> > recent linux-next in Simon's result (36.7 Gb/s vs. 18.2 Gb/s). IMO there
> > must be some latency somewhere.
>
> I think the whole thing here is that you misinterpreted what Eric said.
>
> He is not arguing that some regression did, or did not, happen.
>
> He instead was making the basic statement about the fact that due to
> the lack of paralellness a single stream TCP case is harder to
> optimize for high speed NICs.
>
> That is all.
Thanks, I got it.
I'm actually new to network performance tuning, trying to understand
all the related details. :-)
Thanks,
-- Dexuan
--
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
Powered by blists - more mailing lists