> Subject: Re: Network throughput limits for local VM <-> VM > communication > > 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. I am using two bridges, and yes, in theory, the router should be the only connection between the two guests. However, without VLANs, the tun interface will pass packets to all tap interfaces. It has to, as it doesn't know to which one the packet has to go to. It does not look at packets, it simply copies buffers from userspace to the tap interface in the kernel. The tap interface then eventually drops the packet, if the MAC address does not match its own. So packets will not actually go across both bridges, because the tap interface that should not receive the packet does drop it. However, it does receive the packet and processes it to some extend which causes some overhead. As I was told by someone at KVM/RedHat, this does not happen when using VLANs as then there will be a direct mapping between any tun<->tap device and so no packet replication across multiple tap devices. > > > 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. Yes, I understand you were trying to help and using the -net socket interface would help to narrow down where the problem could be. I just have not yet managed to set this up, but I might do if I find the time in the next days. I was hoping that other people might have seen the same issues I see, but unfortunately I did not get that many replies/suggestions on this issue from the list at all. > > 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? Good question. I will try this out and post the results. Cheers, Anna -- 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
