From mboxrd@z Thu Jan 1 00:00:00 1970 From: Asias He Subject: Re: Does macvtap support host to guest communication? Date: Mon, 18 Apr 2011 23:28:29 +0800 Message-ID: <4DAC589D.8040204@gmail.com> References: <4DABD5BC.2040204@gmail.com> <201104181520.18061.arnd@arndb.de> <4DAC4AF3.3080107@gmail.com> <201104181705.39772.arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ingo Molnar , "Michael S. Tsirkin" , Jason Wang , Pekka Enberg , Amos Kong , kvm@vger.kernel.org To: Arnd Bergmann Return-path: Received: from mail-px0-f179.google.com ([209.85.212.179]:62980 "EHLO mail-px0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755166Ab1DRP3i (ORCPT ); Mon, 18 Apr 2011 11:29:38 -0400 Received: by pxi2 with SMTP id 2so3390679pxi.10 for ; Mon, 18 Apr 2011 08:29:37 -0700 (PDT) In-Reply-To: <201104181705.39772.arnd@arndb.de> Sender: kvm-owner@vger.kernel.org List-ID: On 04/18/2011 11:05 PM, Arnd Bergmann wrote: > On Monday 18 April 2011, Asias He wrote: >> We do need "guest appearing on the same network as the host" support as >> well. The reason I am considering using macvatp instead of tap plus >> brctl is that it simplifies the bridge configuration and it is more >> efficient. > > Right, you certainly don't need to consider tap/brctl any more. > >> However, IMHO, the interface of macvtap is not user friendly, at least >> for me. I have no idea about the technical reasons that make the >> low-level device inaccessible. But if it is accessible, a lot of >> configuration can be eliminated. I know virtualbox's bridge mode has >> this kind of restriction, while VMware's bridge mode does not. > > The main reason is that having a MAC address scan in the regular > networking core would make the common TX case where there is no > macvlan device more complex. Macvtap is derived from the plain > macvlan driver, which used to support only sending out to the > wire until I added the optional bridge mode. > > If you want a regular device to be able to send to a macvlan > port, that would require at least these changes: > > * Add an option to put a plain device into macvlan-bridge mode > * Add support for that option into iproute2 > * Add a hook into dev_queue_xmit() to check for macvlan ports Cool! Arnd, mind to add this feature to macvtap? -- Best Regards, Asias He