Michael S. Tsirkin m...@redhat.com wrote on 02/23/2011 09:25:34 PM:
Sure, will get a build/test on latest bits and send in 1-2 days.
The TX-only patch helped the guest TX path but didn't help
host-guest much (as tested using TCP_MAERTS from the guest).
But with the TX+RX patch,
On Wed, Feb 23, 2011 at 12:18:36PM +0530, Krishna Kumar2 wrote:
Michael S. Tsirkin m...@redhat.com wrote on 02/23/2011 12:09:15 PM:
Hi Michael,
Yes. Michael Tsirkin had wanted to see how the MQ RX patch
would look like, so I was in the process of getting the two
working together.
On Wed, Feb 23, 2011 at 10:52:09AM +0530, Krishna Kumar2 wrote:
Simon Horman ho...@verge.net.au wrote on 02/22/2011 01:17:09 PM:
Hi Simon,
I have a few questions about the results below:
1. Are the (%) comparisons between non-mq and mq virtio?
Yes - mainline kernel with
On Wed, Oct 20, 2010 at 02:24:52PM +0530, Krishna Kumar wrote:
Following set of patches implement transmit MQ in virtio-net. Also
included is the user qemu changes. MQ is disabled by default unless
qemu specifies it.
Hi Krishna,
I have a few questions about the results below:
1. Are the
Simon Horman ho...@verge.net.au wrote on 02/22/2011 01:17:09 PM:
Hi Simon,
I have a few questions about the results below:
1. Are the (%) comparisons between non-mq and mq virtio?
Yes - mainline kernel with transmit-only MQ patch.
2. Was UDP or TCP used?
TCP. I had done some initial
On Wed, Feb 23, 2011 at 10:52:09AM +0530, Krishna Kumar2 wrote:
Simon Horman ho...@verge.net.au wrote on 02/22/2011 01:17:09 PM:
Hi Simon,
I have a few questions about the results below:
1. Are the (%) comparisons between non-mq and mq virtio?
Yes - mainline kernel with
Michael S. Tsirkin m...@redhat.com wrote on 02/23/2011 12:09:15 PM:
Hi Michael,
Yes. Michael Tsirkin had wanted to see how the MQ RX patch
would look like, so I was in the process of getting the two
working together. The patch is ready and is being tested.
Should I send a RFC patch at
On Tue, Nov 09, 2010 at 10:54:57PM +0530, Krishna Kumar2 wrote:
Michael S. Tsirkin m...@redhat.com wrote on 11/09/2010 09:03:25 PM:
Something strange here, right?
1. You are consistently getting 10G/s here, and even with a single
stream?
Sorry, I should have mentioned this
On Tue, Nov 09, 2010 at 08:58:44PM +0530, Krishna Kumar2 wrote:
Michael S. Tsirkin m...@redhat.com wrote on 11/09/2010 06:52:39 PM:
Re: [v3 RFC PATCH 0/4] Implement multiqueue virtio-net
On Mon, Oct 25, 2010 at 09:20:38PM +0530, Krishna Kumar2 wrote:
Krishna Kumar2/India/i
On Tue, Nov 09, 2010 at 10:08:21AM +0530, Krishna Kumar2 wrote:
Michael S. Tsirkin m...@redhat.com wrote on 10/26/2010 02:27:09 PM:
Re: [v3 RFC PATCH 0/4] Implement multiqueue virtio-net
On Mon, Oct 25, 2010 at 09:20:38PM +0530, Krishna Kumar2 wrote:
Krishna Kumar2/India/i...@ibmin
Michael S. Tsirkin m...@redhat.com wrote on 11/09/2010 09:03:25 PM:
Something strange here, right?
1. You are consistently getting 10G/s here, and even with a single
stream?
Sorry, I should have mentioned this though I had stated in my
earlier mails. Each test result has two
Michael S. Tsirkin m...@redhat.com wrote on 10/26/2010 02:27:09 PM:
Re: [v3 RFC PATCH 0/4] Implement multiqueue virtio-net
On Mon, Oct 25, 2010 at 09:20:38PM +0530, Krishna Kumar2 wrote:
Krishna Kumar2/India/i...@ibmin wrote on 10/20/2010 02:24:52 PM:
Any feedback, comments, objections
On Thu, Oct 28, 2010 at 12:48:57PM +0530, Krishna Kumar2 wrote:
Krishna Kumar2/India/IBM wrote on 10/28/2010 10:44:14 AM:
Results for UDP BW tests (unidirectional, sum across
3 iterations, each iteration of 45 seconds, default
netperf, vhosts bound to cpus 0-3; no other
On Thu, Oct 28, 2010 at 12:48:57PM +0530, Krishna Kumar2 wrote:
Krishna Kumar2/India/IBM wrote on 10/28/2010 10:44:14 AM:
Results for UDP BW tests (unidirectional, sum across
3 iterations, each iteration of 45 seconds, default
netperf, vhosts bound to cpus 0-3; no other
On Fri, 29 Oct 2010 13:26 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Thu, Oct 28, 2010 at 12:48:57PM +0530, Krishna Kumar2 wrote:
Krishna Kumar2/India/IBM wrote on 10/28/2010 10:44:14 AM:
In practice users are very unlikely to pin threads to CPUs.
I may be misunderstanding what
Michael S. Tsirkin m...@redhat.com
I think we discussed the need for external to guest testing
over 10G. For large messages we should not see any change
but you should be able to get better numbers for small messages
assuming a MQ NIC card.
For external host, there is a
On Thu, Oct 28, 2010 at 11:42:05AM +0530, Krishna Kumar2 wrote:
Michael S. Tsirkin m...@redhat.com
I think we discussed the need for external to guest testing
over 10G. For large messages we should not see any change
but you should be able to get better numbers for small messages
Krishna Kumar2/India/IBM wrote on 10/28/2010 10:44:14 AM:
Results for UDP BW tests (unidirectional, sum across
3 iterations, each iteration of 45 seconds, default
netperf, vhosts bound to cpus 0-3; no other tuning):
Is binding vhost threads to CPUs really required?
Michael S. Tsirkin m...@redhat.com wrote on 10/26/2010 04:39:13 PM:
(merging two posts into one)
I think we discussed the need for external to guest testing
over 10G. For large messages we should not see any change
but you should be able to get better numbers for small messages
assuming a MQ
On Thu, Oct 28, 2010 at 10:44:14AM +0530, Krishna Kumar2 wrote:
Michael S. Tsirkin m...@redhat.com wrote on 10/26/2010 04:39:13 PM:
(merging two posts into one)
I think we discussed the need for external to guest testing
over 10G. For large messages we should not see any change
but you
On Mon, Oct 25, 2010 at 09:20:38PM +0530, Krishna Kumar2 wrote:
Krishna Kumar2/India/i...@ibmin wrote on 10/20/2010 02:24:52 PM:
Any feedback, comments, objections, issues or bugs about the
patches? Please let me know if something needs to be done.
Some more test results:
Krishna Kumar2/India/IBM wrote on 10/26/2010 10:40:35 AM:
I am trying to wrap my head around kernel/user interface here.
E.g., will we need another incompatible change when we add multiple RX
queues?
Though I added a 'mq' option to qemu, there shouldn't be
any incompatibility between old
On Tue, Oct 26, 2010 at 02:38:53PM +0530, Krishna Kumar2 wrote:
Results for UDP BW tests (unidirectional, sum across
3 iterations, each iteration of 45 seconds, default
netperf, vhosts bound to cpus 0-3; no other tuning):
Is binding vhost threads to CPUs really required?
What happens if we let
Michael S. Tsirkin m...@redhat.com
On Tue, Oct 26, 2010 at 02:38:53PM +0530, Krishna Kumar2 wrote:
Results for UDP BW tests (unidirectional, sum across
3 iterations, each iteration of 45 seconds, default
netperf, vhosts bound to cpus 0-3; no other tuning):
Is binding vhost threads to
On Tue, Oct 26, 2010 at 03:31:39PM +0530, Krishna Kumar2 wrote:
Michael S. Tsirkin m...@redhat.com
On Tue, Oct 26, 2010 at 02:38:53PM +0530, Krishna Kumar2 wrote:
Results for UDP BW tests (unidirectional, sum across
3 iterations, each iteration of 45 seconds, default
netperf, vhosts
43.02 35.97 28.89 -.11-5.31
128 38.54 33.88 27.19 -4.79 -9.54
_
BW: 34.4% CPU/RCPU: 35.9%,27.8% SD/RSD: -4.1%,-9.3%
Thanks,
- KK
[v3 RFC PATCH 0/4] Implement multiqueue virtio-net
Following set of patches implement
%
Thanks,
- KK
[v3 RFC PATCH 0/4] Implement multiqueue virtio-net
Following set of patches implement transmit MQ in virtio-net. Also
included is the user qemu changes. MQ is disabled by default unless
qemu specifies it.
Changes from rev2
Michael S. Tsirkin m...@redhat.com wrote on 10/25/2010 09:47:18 PM:
Any feedback, comments, objections, issues or bugs about the
patches? Please let me know if something needs to be done.
I am trying to wrap my head around kernel/user interface here.
E.g., will we need another incompatible
Following set of patches implement transmit MQ in virtio-net. Also
included is the user qemu changes. MQ is disabled by default unless
qemu specifies it.
Changes from rev2:
--
1. Define (in virtio_net.h) the maximum send txqs; and use in
Michael S. Tsirkin m...@redhat.com wrote on 10/12/2010 10:39:07 PM:
Sorry for the delay, I was sick last couple of days. The results
with your patch are (%'s over original code):
Code BW% CPU% RemoteCPU
MQ (#txq=16) 31.4% 38.42% 6.41%
MQ+MST
On Thu, Oct 14, 2010 at 01:28:58PM +0530, Krishna Kumar2 wrote:
Michael S. Tsirkin m...@redhat.com wrote on 10/12/2010 10:39:07 PM:
Sorry for the delay, I was sick last couple of days. The results
with your patch are (%'s over original code):
Code BW% CPU%
Michael S. Tsirkin m...@redhat.com
What other shared TX/RX locks are there? In your setup, is the same
macvtap socket structure used for RX and TX? If yes this will create
cacheline bounces as sk_wmem_alloc/sk_rmem_alloc share a cache line,
there might also be contention on the lock
Krishna Kumar2/India/IBM wrote on 10/14/2010 02:34:01 PM:
void vhost_poll_queue(struct vhost_poll *poll)
{
struct vhost_virtqueue *vq = vhost_find_vq(poll);
vhost_work_queue(vq, poll-work);
}
Since poll batches packets, find_vq does not seem to add much
to the CPU
Krishna Kumar2/India/IBM wrote on 10/14/2010 05:47:54 PM:
Sorry, it should read txq=8 below.
- KK
There's a significant reduction in CPU/SD utilization with your
patch. Following is the performance of ORG vs MQ+mm patch:
_
Org
Michael S. Tsirkin m...@redhat.com wrote on 10/06/2010 07:04:31 PM:
On Fri, Sep 17, 2010 at 03:33:07PM +0530, Krishna Kumar wrote:
For 1 TCP netperf, I ran 7 iterations and summed it. Explanation
for degradation for 1 stream case:
I thought about possible RX/TX contention reasons, and I
On Tuesday 05 October 2010, Krishna Kumar2 wrote:
After testing various combinations of #txqs, #vhosts, #netperf
sessions, I think the drop for 1 stream is due to TX and RX for
a flow being processed on different cpus. I did two more tests:
1. Pin vhosts to same CPU:
- BW drop is
On Fri, Sep 17, 2010 at 03:33:07PM +0530, Krishna Kumar wrote:
For 1 TCP netperf, I ran 7 iterations and summed it. Explanation
for degradation for 1 stream case:
I thought about possible RX/TX contention reasons, and I realized that
we get/put the mm counter all the time. So I write the
...@codemonkey.ws
Subject
Re: [v2 RFC PATCH 0/4] Implement multiqueue virtio-net
On Fri, Sep 17, 2010 at 03:33:07PM +0530, Krishna Kumar wrote:
For 1 TCP netperf, I ran 7 iterations and summed it. Explanation
for degradation for 1 stream case:
I thought about possible RX/TX contention
Arnd Bergmann a...@arndb.de wrote on 10/06/2010 05:49:00 PM:
I don't see any reasons mentioned above. However, for higher
number of netperf sessions, I see a big increase in retransmissions:
___
#netperf ORG NEW
BW (#retr)
Michael S. Tsirkin m...@redhat.com wrote on 10/05/2010 11:53:23 PM:
Any idea where does this come from?
Do you see more TX interrupts? RX interrupts? Exits?
Do interrupts bounce more between guest CPUs?
4. Identify reasons for single netperf BW regression.
After testing various
On Wednesday 06 October 2010 19:14:42 Krishna Kumar2 wrote:
Arnd Bergmann a...@arndb.de wrote on 10/06/2010 05:49:00 PM:
I don't see any reasons mentioned above. However, for higher
number of netperf sessions, I see a big increase in retransmissions:
On Wed, Oct 06, 2010 at 11:13:31PM +0530, Krishna Kumar2 wrote:
Michael S. Tsirkin m...@redhat.com wrote on 10/05/2010 11:53:23 PM:
Any idea where does this come from?
Do you see more TX interrupts? RX interrupts? Exits?
Do interrupts bounce more between guest CPUs?
4. Identify
Michael S. Tsirkin m...@redhat.com wrote on 09/19/2010 06:14:43 PM:
Could you document how exactly do you measure multistream bandwidth:
netperf flags, etc?
All results were without any netperf flags or system tuning:
for i in $list
do
netperf -c -C -l 60 -H 192.168.122.1
On Tue, Oct 05, 2010 at 04:10:00PM +0530, Krishna Kumar2 wrote:
Michael S. Tsirkin m...@redhat.com wrote on 09/19/2010 06:14:43 PM:
Could you document how exactly do you measure multistream bandwidth:
netperf flags, etc?
All results were without any netperf flags or system tuning:
On Fri, Sep 17, 2010 at 03:33:07PM +0530, Krishna Kumar wrote:
For 1 TCP netperf, I ran 7 iterations and summed it. Explanation
for degradation for 1 stream case:
Could you document how exactly do you measure multistream bandwidth:
netperf flags, etc?
1. Without any tuning, BW falls
Following patches implement transmit MQ in virtio-net. Also
included is the user qemu changes. MQ is disabled by default
unless qemu specifies it.
1. This feature was first implemented with a single vhost.
Testing showed 3-8% performance gain for upto 8 netperf
sessions (and sometimes 16),
On Mon, Sep 13, 2010 at 09:53:40PM +0530, Krishna Kumar2 wrote:
Michael S. Tsirkin m...@redhat.com wrote on 09/13/2010 05:20:55 PM:
Results with the original kernel:
_
# BW SD RSD
__
1 20903 1 6
Michael S. Tsirkin m...@redhat.com wrote on 09/13/2010 05:20:55 PM:
Results with the original kernel:
_
# BW SD RSD
__
1 20903 1 6
2 21963 6 25
4 22042 23 102
8
On Thu, Sep 09, 2010 at 03:15:53PM +0530, Krishna Kumar2 wrote:
Krishna Kumar2/India/IBM wrote on 09/08/2010 10:17:49 PM:
Some more results and likely cause for single netperf
degradation below.
Guest - Host (single netperf):
I am getting a drop of almost 20%. I am trying to figure
Michael S. Tsirkin m...@redhat.com wrote on 09/12/2010 05:10:25 PM:
SINGLE vhost (Guest - Host):
1 netperf:BW: 10.7% SD: -1.4%
4 netperfs: BW: 3%SD: 1.4%
8 netperfs: BW: 17.7% SD: -10%
16 netperfs: BW: 4.7% SD: -7.0%
32 netperfs: BW:
Krishna Kumar2/India/IBM wrote on 09/08/2010 10:17:49 PM:
Some more results and likely cause for single netperf
degradation below.
Guest - Host (single netperf):
I am getting a drop of almost 20%. I am trying to figure out
why.
Host - guest (single netperf):
I am getting an improvement
On Wednesday 08 September 2010, Krishna Kumar2 wrote:
On Wednesday 08 September 2010, Krishna Kumar2 wrote:
The new guest and qemu code work with old vhost-net, just with
reduced
performance, yes?
Yes, I have tested new guest/qemu with old vhost but using
#numtxqs=1 (or not
Krishna Kumar2/India/IBM wrote on 09/09/2010 03:15:53 PM:
I will start a full test run of original vs submitted
code with minimal tuning (Avi also suggested the same),
and re-send. Please let me know if you need any other
data.
Same patch, only change is that I ran taskset -p 03
all vhost
Arnd Bergmann a...@arndb.de wrote on 09/09/2010 04:10:27 PM:
Can you live migrate a new guest from new-qemu/new-kernel
to old-qemu/old-kernel, new-qemu/old-kernel and old-qemu/new-kernel?
If not, do we need to support all those cases?
I have not tried this, though I added some
On 9/9/2010 2:45 AM, Krishna Kumar2 wrote:
Krishna Kumar2/India/IBM wrote on 09/08/2010 10:17:49 PM:
Some more results and likely cause for single netperf
degradation below.
Guest - Host (single netperf):
I am getting a drop of almost 20%. I am trying to figure out
why.
Host - guest
Sridhar Samudrala s...@us.ibm.com wrote on 09/10/2010 04:30:24 AM:
I remember seeing similar issue when using a separate vhost thread for
TX and
RX queues. Basically, we should have the same vhost thread process a
TCP flow
in both directions. I guess this allows the data and ACKs to be
On 09/08/2010 10:28 AM, Krishna Kumar wrote:
Following patches implement Transmit mq in virtio-net. Also
included is the user qemu changes.
1. This feature was first implemented with a single vhost.
Testing showed 3-8% performance gain for upto 8 netperf
sessions (and sometimes 16),
On Wed, Sep 08, 2010 at 12:58:59PM +0530, Krishna Kumar wrote:
Following patches implement Transmit mq in virtio-net. Also
included is the user qemu changes.
1. This feature was first implemented with a single vhost.
Testing showed 3-8% performance gain for upto 8 netperf
sessions
On Wed, Sep 08, 2010 at 12:58:59PM +0530, Krishna Kumar wrote:
1. mq RX patch is also complete - plan to submit once TX is OK.
It's good that you split patches, I think it would be interesting to see
the RX patches at least once to complete the picture.
You could make it a separate patchset, tag
Avi Kivity a...@redhat.com wrote on 09/08/2010 01:17:34 PM:
On 09/08/2010 10:28 AM, Krishna Kumar wrote:
Following patches implement Transmit mq in virtio-net. Also
included is the user qemu changes.
1. This feature was first implemented with a single vhost.
Testing showed 3-8%
Michael S. Tsirkin m...@redhat.com wrote on 09/08/2010 01:40:11 PM:
___
TCP (#numtxqs=2)
N# BW1 BW2(%) SD1 SD2(%) RSD1RSD2
(%)
Hi Michael,
Michael S. Tsirkin m...@redhat.com wrote on 09/08/2010 01:43:26 PM:
On Wed, Sep 08, 2010 at 12:58:59PM +0530, Krishna Kumar wrote:
1. mq RX patch is also complete - plan to submit once TX is OK.
It's good that you split patches, I think it would be interesting to see
the RX
On 09/08/2010 12:22 PM, Krishna Kumar2 wrote:
Avi Kivitya...@redhat.com wrote on 09/08/2010 01:17:34 PM:
On 09/08/2010 10:28 AM, Krishna Kumar wrote:
Following patches implement Transmit mq in virtio-net. Also
included is the user qemu changes.
1. This feature was first implemented
Avi Kivity a...@redhat.com wrote on 09/08/2010 02:58:21 PM:
1. This feature was first implemented with a single vhost.
Testing showed 3-8% performance gain for upto 8 netperf
sessions (and sometimes 16), but BW dropped with more
sessions. However, implementing per-txq
On Wed, Sep 08, 2010 at 02:53:03PM +0530, Krishna Kumar2 wrote:
Michael S. Tsirkin m...@redhat.com wrote on 09/08/2010 01:40:11 PM:
___
TCP (#numtxqs=2)
N# BW1 BW2(%)
Michael S. Tsirkin m...@redhat.com wrote on 09/08/2010 04:18:33 PM:
___
TCP (#numtxqs=2)
N# BW1 BW2(%) SD1 SD2(%) RSD1
RSD2
(%)
On Wednesday 08 September 2010, Krishna Kumar2 wrote:
The new guest and qemu code work with old vhost-net, just with reduced
performance, yes?
Yes, I have tested new guest/qemu with old vhost but using
#numtxqs=1 (or not passing any arguments at all to qemu to
enable MQ). Giving numtxqs
Michael S. Tsirkin m...@redhat.com wrote on 09/08/2010 01:40:11 PM:
___
UDP (#numtxqs=8)
N# BW1 BW2 (%) SD1 SD2 (%)
68 matches
Mail list logo
