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