From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57628) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TdbqF-0002Zu-0E for qemu-devel@nongnu.org; Wed, 28 Nov 2012 02:13:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TdbqD-0004cX-Nr for qemu-devel@nongnu.org; Wed, 28 Nov 2012 02:13:54 -0500 Received: from 69.169.164.127.provo.static.broadweavenetworks.net ([69.169.164.127]:41274 helo=baldr.dev-zero.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TdbqD-0004cP-IN for qemu-devel@nongnu.org; Wed, 28 Nov 2012 02:13:53 -0500 Message-ID: <50B5B9BD.6070301@dev-zero.net> Date: Wed, 28 Nov 2012 00:14:05 -0700 From: Mike Lovell MIME-Version: 1.0 References: <1340602924-3231-1-git-send-email-mike@dev-zero.net> <50B3A494.3050002@dev-zero.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] net: RFC New Socket-Based, Switched Network Backend (QDES) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Anthony Liguori , qemu-devel On 11/27/2012 05:42 AM, Stefan Hajnoczi wrote: > On Mon, Nov 26, 2012 at 6:19 PM, Mike Lovell 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