From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [RFC PATCH] macvlan: Introduce a PASSTHRU mode to takeover the underlying device Date: Wed, 27 Oct 2010 16:05:29 +0200 Message-ID: <201010271605.29201.arnd@arndb.de> References: <1288131578.7582.49.camel@sridhar.beaverton.ibm.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Cc: kaber@trash.net, netdev , "kvm@vger.kernel.org" To: Sridhar Samudrala Return-path: Received: from moutng.kundenserver.de ([212.227.17.10]:58750 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761321Ab0J0OFm (ORCPT ); Wed, 27 Oct 2010 10:05:42 -0400 In-Reply-To: <1288131578.7582.49.camel@sridhar.beaverton.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wednesday 27 October 2010, Sridhar Samudrala wrote: > With the current default macvtap mode, a KVM guest using virtio with > macvtap backend has the following limitations. > - cannot change/add a mac address on the guest virtio-net > - cannot create a vlan device on the guest virtio-net > - cannot enable promiscuous mode on guest virtio-net > > This patch introduces a new mode called 'passthru' when creating a > macvlan device which allows takeover of the underlying device and > passing it to a guest using virtio with macvtap backend. > > Only one macvlan device is allowed in passthru mode and it inherits > the mac address from the underlying device and sets it in promiscuous > mode to receive and forward all the packets. Interesting approach. It somewhat stretches the definition of the macvlan concept, but it does sound useful to have. I was thinking about adding a new tap frontend driver that could share some code with macvtap and do only the takeover but not use macvlan as a base. I believe that would be a cleaner abstraction, but your code has two advantages in that the implementation is much simpler and that it can share a fair amount of the infrastructure that we're putting into qemu/libvirt/etc. Arnd PS: Please add a Signed-off-by: line when sending a patch, even for discussion.