[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [Bug 1066055] Re: Network performance regression with vde_s
From: |
Edivaldo de Araujo Pereira |
Subject: |
[Qemu-devel] [Bug 1066055] Re: Network performance regression with vde_switch |
Date: |
Mon, 15 Oct 2012 21:46:06 -0000 |
Hi Stefan,
Thank you, very much for taking the time to help me, and excuse me for
not seeing your answer early...
I've run the procedure you pointed me out, and the result is:
0d8d7690850eb0cf2b2b60933cf47669a6b6f18f is the first bad commit
commit 0d8d7690850eb0cf2b2b60933cf47669a6b6f18f
Author: Amit Shah <address@hidden>
Date: Tue Sep 25 00:05:15 2012 +0530
virtio: Introduce virtqueue_get_avail_bytes()
The current virtqueue_avail_bytes() is oddly named, and checks if a
particular number of bytes are available in a vq. A better API is to
fetch the number of bytes available in the vq, and let the caller do
what's interesting with the numbers.
Introduce virtqueue_get_avail_bytes(), which returns the number of bytes
for buffers marked for both, in as well as out. virtqueue_avail_bytes()
is made a wrapper over this new function.
Signed-off-by: Amit Shah <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
:040000 040000 1a58b06a228651cf844621d9ee2f49b525e36c93
e09ea66ce7f6874921670b6aeab5bea921a5227d M hw
I tried to revert that patch in the latest version, but it obviously
didnt work; I'm trying to figure out the problem, but I don't know very
well the souce code, so I think it's going to take some time. For now,
it's all I could do.
Thank you, again.
Edivaldo
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1066055
Title:
Network performance regression with vde_switch
Status in QEMU:
New
Bug description:
I've noticed a significant network performance regression when using
vde_switch, starting about one week ago (10/05/2012); before that
date, I used to get about 1.5 Gbits host to guest, but now I can only
get about 320 Mbits; I didn't find any modification in net/vde.*, just
in hw/virtio*.
My command line:
qemu-system-i386 -cdrom /bpd/bpd.iso -m 512 -boot d -enable-kvm \
-localtime -ctrl-grab -usbdevice tablet \
-device
virtio-net-pci,mac=52:54:00:18:01:01,netdev=vde0,tx=bh,ioeventfd=on,x-txburst=32
\
-netdev vde,id=vde0 -vga std -tb-size 2M -cpu host -clock unix
My host runs a kernel 3.6.1 and my guest runs a kernel 3.5.4; the same
problem happens with other host and guest versions, too.
I know there are better ways of running a guest, but using vde I get a
cleaner environment in the host (just one tun/tap interface to
manage...), which is quite good when running some accademic
experiments.
Interestingly, at the same time I've noticed a performance enhancement
of about 25~30 % when using a tun/tap interface, bridged or not.
Thank you, very much.
Edivaldo de Araujo Pereira
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1066055/+subscriptions
- [Qemu-devel] [PATCH v4 0/5] Better allocation of code_gen_buffer, Richard Henderson, 2012/10/16
- [Qemu-devel] [PATCH 1/5] exec: Split up and tidy code_gen_buffer, Richard Henderson, 2012/10/16
- [Qemu-devel] [PATCH 3/5] exec: Do not use absolute address hints for code_gen_buffer with -fpie, Richard Henderson, 2012/10/16
- [Qemu-devel] [PATCH 4/5] exec: Allocate code_gen_prologue from code_gen_buffer, Richard Henderson, 2012/10/16
- [Qemu-devel] [PATCH 5/5] exec: Make MIN_CODE_GEN_BUFFER_SIZE private to exec.c, Richard Henderson, 2012/10/16
- [Qemu-devel] [PATCH 2/5] exec: Don't make DEFAULT_CODE_GEN_BUFFER_SIZE too large, Richard Henderson, 2012/10/16