From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57424) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TdM67-0006Bk-6y for qemu-devel@nongnu.org; Tue, 27 Nov 2012 09:25:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TdM65-0004ps-LV for qemu-devel@nongnu.org; Tue, 27 Nov 2012 09:25:15 -0500 Received: from e28smtp06.in.ibm.com ([122.248.162.6]:44146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TdM64-0004p5-W1 for qemu-devel@nongnu.org; Tue, 27 Nov 2012 09:25:13 -0500 Received: from /spool/local by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 27 Nov 2012 19:55:09 +0530 Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qAREP6pB7733712 for ; Tue, 27 Nov 2012 19:55:07 +0530 Received: from d28av04.in.ibm.com (loopback [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qARJsvHR006970 for ; Wed, 28 Nov 2012 06:54:58 +1100 From: Anthony Liguori In-Reply-To: References: <1340602924-3231-1-git-send-email-mike@dev-zero.net> <50B3A494.3050002@dev-zero.net> Date: Tue, 27 Nov 2012 08:24:54 -0600 Message-ID: <877gp7azt5.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 , Mike Lovell Cc: qemu-devel Stefan Hajnoczi writes: > 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. Perhaps this is a dumb question, but wouldn't it be trivial to write a VXLAN proxy that added a VXLAN tag to ethernet frames from -net socket? Obviously, this could also be done with the normal linux tools at the tun/tap layer too. I think we should resist adding a bunch of stuff to the networking layer just because we can. Otherwise we'll end up reinventing the Linux networking layer in QEMU. Regards, Anthony Liguori > > Stefan