[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Or Gerlitz
Subject: Re: [Qemu-devel] [PATCH] net: add raw backend
Date: Thu, 16 Jul 2009 11:29:34 +0300
User-agent: Thunderbird (Windows/20070221)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]