Re: [Qemu-devel] How to lock-up your tap-based VM network

[Paul Brook <paul@codesourcery.com>]

> 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.

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.

Paul