From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jerry Chu <hkchu@google.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: qlen check in tun.c
Date: Mon, 24 Jun 2013 13:13:35 +0800 [thread overview]
Message-ID: <51C7D57F.6080803@redhat.com> (raw)
In-Reply-To: <20130620080725.GB23621@redhat.com>
On 06/20/2013 04:07 PM, Michael S. Tsirkin wrote:
> On Wed, Jun 19, 2013 at 12:39:34PM -0700, 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.
>> We haven't figured out an optimal strategy for thruput vs latency, but
>> suffice to
>> say 500 is too small.
>>
>> Jerry
> Maybe TSO is off for you?
> With TSO you can get 64Kbyte packets, 500 of these is 30 Mbytes!
> We really should consider setting byte limits, not packet limits.
Do you mean BQL for tuntap?
next prev parent reply other threads:[~2013-06-24 5:13 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
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 [this message]
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=51C7D57F.6080803@redhat.com \
--to=jasowang@redhat.com \
--cc=hkchu@google.com \
--cc=mst@redhat.com \
--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.