netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Shirley Ma <mashirle@us.ibm.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	netdev@vger.kernel.org, Tom Lendacky <toml@us.ibm.com>,
	Cristian Viana <vianac@br.ibm.com>
Subject: Re: [PATCH 2/2] vhost-net: add a spin_threshold parameter
Date: Tue, 21 Feb 2012 14:38:13 +0800	[thread overview]
Message-ID: <4F433BD5.1070400@redhat.com> (raw)
In-Reply-To: <1329805716.24119.3.camel@localhost.localdomain>

On 02/21/2012 02:28 PM, Shirley Ma wrote:
> On Tue, 2012-02-21 at 13:34 +0800, Jason Wang wrote:
>> On 02/21/2012 09:35 AM, Shirley Ma wrote:
>>> We tried similar approach before by using a minimum timer for
>> handle_tx
>>> to stay in the loop to accumulate more packets before enabling the
>> guest
>>> notification. It did have better TCP_RRs, UDP_RRs results. However,
>> we
>>> think this is just a debug patch. We really need to understand why
>>> handle_tx can't see more packets to process for multiple instances
>>> request/response type of workload first. Spinning in this loop is
>> not a
>>> good solution.
>> Spinning help for the latency, but looks like we need some adaptive
>> method to adjust the threshold dynamically such as monitor the
>> minimum
>> time gap between two packets. For throughput, if we can improve the
>> batching of small packets we can improve it. I've tired to use event
>> index to delay the tx kick until a specified number of packets were
>> batched in the virtqueue. Test shows improvement of throughput in
>> small
>> packets as the number of #exit were reduced greatly ( the
>> packets/#exit
>> and cpu utilization were increased), but it damages the performance
>> of
>> other. This is only for debug, but it confirms that there's something
>> we
>> need to improve the batching.
> Our test case was 60 instances 256/256 bytes tcp_rrs or udp_rrs. In
> theory there should be multiple packets in the queue by the time vhost
> gets notified, but from debugging output, there was only a few or even
> one packet in the queue. So the questions here why the time gap between
> two packets is that big?
>
> Shirley

Not sure whether it's related but did you try to disable the nagle 
algorithm during the test?

  reply	other threads:[~2012-02-21  6:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-17 23:02 [PATCH 0/2][RFC] vhost: improve transmit rate with virtqueue polling Anthony Liguori
2012-02-17 23:02 ` [PATCH 1/2] vhost: allow multiple workers threads Anthony Liguori
2012-02-19 14:41   ` Michael S. Tsirkin
2012-02-20 15:50     ` Tom Lendacky
2012-02-20 19:27       ` Michael S. Tsirkin
2012-02-20 19:46         ` Anthony Liguori
2012-02-20 21:00           ` Michael S. Tsirkin
2012-02-21  1:04             ` Shirley Ma
2012-02-21  3:21               ` Michael S. Tsirkin
2012-02-21  4:03                 ` Shirley Ma
2012-03-05 13:21                   ` Anthony Liguori
2012-03-05 20:43                     ` Shirley Ma
2012-02-21  4:32           ` Jason Wang
2012-02-21  4:51     ` Jason Wang
2012-02-17 23:02 ` [PATCH 2/2] vhost-net: add a spin_threshold parameter Anthony Liguori
2012-02-19 14:51   ` Michael S. Tsirkin
2012-02-21  1:35     ` Shirley Ma
2012-02-21  5:34       ` Jason Wang
2012-02-21  6:28         ` Shirley Ma
2012-02-21  6:38           ` Jason Wang [this message]
2012-02-21 11:09             ` Shirley Ma
2012-02-21 16:08             ` Sridhar Samudrala
2012-03-12  8:12   ` Dor Laor

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=4F433BD5.1070400@redhat.com \
    --to=jasowang@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=mashirle@us.ibm.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=toml@us.ibm.com \
    --cc=vianac@br.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).