On Wednesday 10 June 2009, Fischer, Anna wrote: > > Have you tried eliminating VLAN to simplify the setup? > > No - but there is a relating bug in the tun/tap interface (well, it is not > really a bug but simply the way tun/tap works) that will cause packets to > be replicated on all the tap interfaces (across all bridges attached to > those) if I do not configure VLANs. This will result in a system that is > even more overloaded. I had discovered this a while back when running > UDP stress tests under 10G. Not sure I understand. Do you mean you have all three guests connected to the same bridge? If you want the router guest to be the only connection, you should not connect the two bridges anywhere else, so I don't see how packets can go from one bridge to the other one, except through the router. > > Does it change when the guests communicate over a -net socket interface > > with your router instead of the -net tap + bridge in the host? > > I have not tried this - I need the bridge in the network data path for > some testing, so using the -net socket interface would not solve my problem. I did not mean this to solve your problem but to hunt down the bug. If the problem only exists with the host bridge device, we should look there, but if it persists, we can probably rule out the tap, bridge and vlan code in the host as the problem source. > However, I have just today managed to get around this bug by using the > e1000 QEMU emulated NIC model and this seems to do the trick. Now the > throughput is still very low, but that might simply be because my system > is too weak. When using the e1000 model instead of rtl8139 or virtio, > I do not have any network crashes any more. That could either indicate a bug in rtl8139 and virtio, or that the specific timing of the e1000 model hides this bug. What happens if only one side uses e1000 while the other still uses virtio? What about any of the other models? Arnd <>< -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
