qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] net: RFC New Socket-Based, Switched Network Backend (QD


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] net: RFC New Socket-Based, Switched Network Backend (QDES)
Date: Sat, 24 Nov 2012 16:21:25 +0100

On Mon, Jun 25, 2012 at 7:42 AM, Mike Lovell <address@hidden> wrote:
> This is what I've been calling QDES or QEMU Distributed Ethernet Switch. I
> first had the idea when I was playing with the udp and mcast socket network
> backends while exploring how to build a VM infrastructure. I liked the idea of
> using the sockets backends cause it doesn't require escalated permissions to
> configure and run as well as the ability to talk over IP networks.

Hi Mike,
I was just reading the VXLAN spec and Linux code when I realized this
is similar to your QDES approach:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d342894c5d2f8c7df194c793ec4059656e09ca31
http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02

If you're still hacking on QDES you may be interested.

VXLAN is a VLAN mechanism that gets around the 12-bit 802.1Q tag size.
 In large deployments it may be necessary to have more than 4096
VLANs, this is where VXLAN comes in.

It's a tiny header with VXLAN Network ID that encapsulates Ethernet inside UDP:

[Outer Ethernet][IP][UDP] [VXLAN] [Inner Ethernet][...]

UDP is used as follows:
1. If the host has already learnt an Inner MAC -> Outer IP mapping,
then it transmits a unicast UDP packet.
2. Otherwise it transmits a multicast UDP packet.

That means all hosts join a multicast group - this enables broadcast
similar to what you've done in your patches.

Typically traffic from a VM on Host A to another VM on Host B will use
unicast UDP because the Inner MAC -> Outer IP mapping has been learnt.

I'm not sure if it makes sense to implement VXLAN in QEMU because the
multicast UDP socket uses a well-known port.  I guess that means
multiple QEMUs running on the same host cannot use VXLAN unless they
bind to unique IP addresses.  At that point we lose the advantage of a
pure userspace implementation and might as well use the kernel
implementation (or OpenVSwitch) with tap devices.

Anyway, it's still interesting and maybe there's a way to solve this.

Stefan



reply via email to

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