From: Rick Jones <rick.jones2@hp.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>,
Emmanuel Jeanvoine <emmanuel.jeanvoine@inria.fr>,
netdev@vger.kernel.org
Subject: Re: Poor TCP bandwidth between network namespaces
Date: Fri, 08 Feb 2013 17:54:55 -0800 [thread overview]
Message-ID: <5115AC6F.50305@hp.com> (raw)
In-Reply-To: <1360373618.6696.2.camel@edumazet-glaptop>
On 02/08/2013 05:33 PM, Eric Dumazet wrote:
> On Mon, 2013-02-04 at 23:52 +0100, Hannes Frederic Sowa wrote:
>> On Mon, Feb 04, 2013 at 03:43:20PM +0100, Emmanuel Jeanvoine wrote:
>>> I'm wondering why the overhead is so high when performing TCP
>>> transfers between two network namespaces. Do you have any idea about
>>> this issue? And possibly, how to increase the bandwidth (without
>>> modifying the MTU on the veths) between network namespaces?
>>
>> You could try Eric's patch (already in net-next) and have a look at the rest
>> of the discussion:
>>
>> http://article.gmane.org/gmane.linux.network/253589
>
> Another thing to consider is the default MTU value :
>
> 65536 for lo, and 1500 for veth
>
> It easily explains half performance for veth
>
> One another thing is the tx-nocache-copy setting, this can explain some
> extra percents.
Whenever I want to avoid matters of MTU, I try going with a test that
never sends anything larger than the smaller of the MTUs involved. One
such example might be (aggregate) netperf TCP_RR tests. Matters of path
length have a much more difficult time "hiding" from a TCP_RR (or
UDP_RR) test than a bulk transfer test.
happy benchmarking,
rick jones
next prev parent reply other threads:[~2013-02-09 1:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-04 14:43 Poor TCP bandwidth between network namespaces Emmanuel Jeanvoine
2013-02-04 22:52 ` Hannes Frederic Sowa
2013-02-09 1:33 ` Eric Dumazet
2013-02-09 1:54 ` Rick Jones [this message]
2013-02-09 2:17 ` Eric Dumazet
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=5115AC6F.50305@hp.com \
--to=rick.jones2@hp.com \
--cc=emmanuel.jeanvoine@inria.fr \
--cc=eric.dumazet@gmail.com \
--cc=hannes@stressinduktion.org \
--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 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.