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
