From: Rick Jones <rick.jones2@hp•com>
To: Jerry Chu <hkchu@google•com>
Cc: Jason Wang <jasowang@redhat•com>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
"Michael S. Tsirkin" <mst@redhat•com>
Subject: Re: qlen check in tun.c
Date: Wed, 19 Jun 2013 12:49:18 -0700 [thread overview]
Message-ID: <51C20B3E.1050708@hp.com> (raw)
In-Reply-To: <CAPshTCj+2wx=LhHujMqiZc1ptvGbcn+V7P9aAhBELHf6cbL+jg@mail.gmail.com>
On 06/19/2013 12:39 PM, Jerry Chu wrote:
> Hi Jason,
>
> On Tue, Jun 18, 2013 at 8:29 PM, Jason Wang <jasowang@redhat•com> wrote:
>> On 06/19/2013 10:31 AM, Jerry Chu wrote:
>>> In tun_net_xmit() the max qlen is computed as
>>> dev->tx_queue_len / tun->numqueues. For multi-queue configuration the
>>> latter may be way too small, forcing one to adjust txqueuelen based
>>> on number of queues created. (Well the default txqueuelen of
>>> 500/TUN_READQ_SIZE already seems too small even for single queue.)
>>
>> Hi Jerry:
>>
>> Do you have some test result of this? Anyway, tun allows userspace to
>> adjust this value based on its requirement.
>
> Sure, but the default size of 500 is just way too small. queue overflows even
> with a simple single-stream throughput test through Openvswitch due to CPU
> scheduler anomaly. On our loaded multi-stream test even 8192 can't prevent
> queue overflow. But then with 8192 we'll be deep into the "buffer
> bloat" territory.
Assuming this single-stream is a netperf test, what happens when you cap
the socket buffers to 724000 bytes? Put another way, is this simply a
situation where the autotuning of the socket buffers/window is taking a
connection somewhere it shouldn't go?
> We haven't figured out an optimal strategy for thruput vs latency, but
> suffice to say 500 is too small.
Just what is the bandwidthXdelay product through the openvswitch?
happy benchmarking,
rick
next prev parent reply other threads:[~2013-06-19 19:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-19 2:31 qlen check in tun.c Jerry Chu
2013-06-19 3:29 ` Jason Wang
2013-06-19 19:39 ` Jerry Chu
2013-06-19 19:49 ` Rick Jones [this message]
2013-06-19 20:42 ` Jerry Chu
2013-06-19 21:37 ` Rick Jones
2013-06-20 8:07 ` Michael S. Tsirkin
2013-06-24 5:13 ` Jason Wang
2013-06-25 22:23 ` Jerry Chu
2013-06-26 5:23 ` Jason Wang
[not found] ` <CAPshTCjbOnZJ6c2tyLbBqZ3Pz=xi+cBMvi=0BqPDyiXJ+jDDOA@mail.gmail.com>
2013-06-26 5:44 ` Jason Wang
2013-06-21 6:44 ` Jason Wang
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=51C20B3E.1050708@hp.com \
--to=rick.jones2@hp$(echo .)com \
--cc=hkchu@google$(echo .)com \
--cc=jasowang@redhat$(echo .)com \
--cc=mst@redhat$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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