[Qemu-devel] [Bug 1066055] Re: Network performance regression with vde_switch

[Edivaldo de Araujo Pereira]

Hi Stefan

I finally could revert that commit in the latest snapshot; problem was I
needed to revert one later, that modified hw/virtio-serial-bus.c
accordingly; after that reversion, the regression in network performance
went completely away; this confirms my previous identification of the
commit that caused it.

Additionally, I tested your last suggestion, to change '<' to '<=', and
that didn't help; the problem was still there.

By the way, the performance gain I observed ,of about 25~30 % when using
a tun/tap, was in fact just apparent, because it was result of a greater
use of cpu, so it was achieved only when the host was idle; when I
stress the host, with a lot of concurrent guests generating traffic,
there is no gain at all.

Just for confirmation, this is the performance I get with latest
snapshot (8b4a3df8081f3e6f1061ed5cbb303ad623ade66b) running wget in the
guest:

$ wget -O /dev/null http://172.18.1.1/bpd.iso
--2012-10-16 09:10:18--  http://172.18.1.1/bpd.iso
Connecting to 172.18.1.1:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 358979584 (342M) [application/x-iso9660-image]
Saving to: `/dev/null'
100%[======================================================>] 358.979.584 
29,7M/s   in 11s
2012-10-16 09:10:29 (30,3 MB/s) - `/dev/null' saved [358979584/358979584]

The same wget, using the same snapshot, but with that commit reverted
is:

$ wget -O /dev/null http://172.18.1.1/bpd.iso
--2012-10-16 09:15:12--  http://172.18.1.1/bpd.iso
Connecting to 172.18.1.1:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 358979584 (342M) [application/x-iso9660-image]
Saving to: `/dev/null'
100%[======================================================>] 358.979.584  
180M/s   in 1,9s
2012-10-16 09:15:14 (180 MB/s) - `/dev/null' saved [358979584/358979584]

So, as I can see, there is no doubt: that commit is the culprit; as it
was intended to be related just to the quality of the source code (at
least as I can see), but implied in such a cost in performance, I think
it would be better to revert it.

Thank you very much, 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