Re: [Qemu-devel] [PATCH] net: add raw backend

[Or Gerlitz <ogerlitz@voltaire.com>]

Jamie Lokier wrote:
> When using a bridge, you set the IP address on the bridge itself (for example, br0).  DHCP runs on the bridge itself, so does the rest of the Linux host stack, although you can use raw sockets on the other interfaces. But reading and controlling the hardware is done on the interfaces. So if you have some program like NetworkManager which checks if you have a wire plugged into eth0, it has to read eth0 to get the wire status, but it has to run DHCP on br0.
Yes, I understand that if the guest want to communicate with the host in 
a bridged environment, the IP has to be set on the bridge. With "DHCP" 
do you refer to dhcp server or to dhcp relay or something else? I assume 
its not a server, since you mentioned a NON NAT environment.

> A bridge is quite simple to configure. Unfortunately because Linux requires all the IP configuration on the bridge device, but network device control on the network device, bridges don't work well with automatic configuration tools.
seems like this scheme/problem is similar to bonding, where the IP 
configuration is done to the bond device but people may still want to do 
control the slave devices, I am not sure why such tools need the device 
to have an IP, but it seems less relevant for this thread.

> Have you measured it?
Yes, I will send soon some data.

> Unfortunately that's usually impossible. Most switches don't do U turns, and a lot of simple networks don't have any switches except a home router

Again, as I wrote, the U turn can be done in three places: software 
bridge, virtual HW bridge inside the  NIC, or at an external switch. 
With virtualuzation becoming more common, options 2 and 3 will be more 
and more available, where the packet socket approach is valid for both 
of them.

> No, it makes performance _much_ worse if you have packets leaving the host, do a U turn and come back on the same link.  Much better to use a bridge inside the host.  Probably ten times faster because host's internal networking is much faster than a typical gigabit link :-)

My benchmark was focusing on packets per second for VM <--> world and 
not on VM/VM communication. I tend to think that with KVM and the raw 
mode or kernel virtio-net backend with both requiring U turn, the VM/VM 
performance will be no less in most if not all measures (namely, packets 
per second, cpu utilization, bandwidth, latency, etc). Still, its quite 
clear that both these mode can be useful for people that want to max the 
VM <---> world communication performance.


> Sometimes it would be useful to send it outside the host and U turn, but not very often; only for diagnostics I would think.  And even that can be done with Linux bridges, using VLANs :-)
mmm, I wasn't sure if you refer to Linux vlans (8021q devices) or the 
Qemu vlan... can you elaborate?

> If you don't need any host<->VM networking, maybe a raw packet socket is faster
> But are you sure it's faster? I'd want to see measurements before I believe it.
fair enough

Or.