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: Mike Lovell
Subject: Re: [Qemu-devel] net: RFC New Socket-Based, Switched Network Backend (QDES)
Date: Wed, 28 Nov 2012 00:14:05 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 11/27/2012 05:42 AM, Stefan Hajnoczi wrote:
On Mon, Nov 26, 2012 at 6:19 PM, Mike Lovell <address@hidden> wrote:
i think it does still make sense to implement it in QEMU. there isn't a
problem with multiple processes using the same multicast address. the
net_socket_mcast_create function in socket.c already sets the
IP_MULTICAST_LOOP option which makes it so packets get looped back and also
delivered to processes on the same host. that is why there is a check in
qdes_receive to see if the sender is the localAddr and drop it if it is. the
big advantage i see to implementing VXLAN inside QEMU is that it can be done
without any escalated privileges and without reconfiguring the hosts network
configuration.
The part I'm wondering about with VXLAN multicast is whether all QEMU
processes on the host need to receive on the same well-known UDP port.
  Not sure if that's possible with the sockets API.

Stefan

ah. yes. all qemu processes using the same well-known UDP port would receive all multicast packets. the individual processes would then be responsible for checking to make sure the received packets are for the same VNI (VXLAN Network Identifier) that the individual process is configured to use. this would result in some additional processing for every process. it should just be a single int comparison on every packet and an increase of packets for broadcast and multicast packets for all VNIs on the port.

also, the code currently allows for using user defined ports and different udp ports could be used for each network. i don't know if other implementations would allow for specifying a different port though.

mike



reply via email to

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