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

[Mike Lovell <mike@dev-zero.net>]

On 11/27/2012 05:42 AM, Stefan Hajnoczi wrote:
> On Mon, Nov 26, 2012 at 6:19 PM, Mike Lovell <mike@dev-zero.net> 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