> 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
