[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] How to lock-up your tap-based VM network
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] How to lock-up your tap-based VM network |
Date: |
Tue, 13 Apr 2010 14:30:34 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
Paul Brook wrote:
>> But anyway, this flow control mechanism is buggy - what if instead of
>> an interface down, you just have a *slow* guest? That should not push
>> back so much that it makes other guests networking with each other
>> slow down.
>
> The OP described multiple guests connected via a host bridge. In this case it
> is entirely the host's responsibility to arbitrate between multiple guests.
> If
> one interface can block the bridge simply by failing to respond in a timely
> manner then this is a serious bug or misconfiguration of your host bridge.
It's not the bridge, I think it's limited to the tun driver as bridge
participant and how it is configured/used by QEMU.
>
> The reason tap_send exists is because slirp does not implement TCP flow
> control properly. Instead it relies on the can_send hook to only avoid
> dropped packets.
>
> Using this in the tap code is debatable. My guess is that this is a hack to
> workaround guest network stacks that expect throughput to be limited by line
> speed (which is a virtual environment is effectively infinite), have poor
> higher level flow control, and react badly to packet loss.
[ CC'ing some people who should have been involved in establishing the
TX mitigation for tap devices. Full thread under
http://thread.gmane.org/gmane.comp.emulators.qemu/67809 ]
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] How to lock-up your tap-based VM network, Blue Swirl, 2010/04/13