netdev - Re: [RFC PATCH] macvlan: Introduce a PASSTHRU mode to takeover the underlying device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20101102184257.GB2341@redhat.com>
Date:	Tue, 2 Nov 2010 20:42:57 +0200
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Sridhar Samudrala <sri@...ibm.com>
Cc:	kaber@...sh.net, Arnd Bergmann <arnd@...db.de>,
	netdev <netdev@...r.kernel.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [RFC PATCH] macvlan: Introduce a PASSTHRU mode to takeover the
 underlying device

On Tue, Nov 02, 2010 at 11:19:13AM -0700, Sridhar Samudrala wrote:
> On Mon, 2010-11-01 at 10:28 +0200, Michael S. Tsirkin wrote:
> 
>     On Tue, Oct 26, 2010 at 03:19:38PM -0700, 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.
>     >
>     > Thanks
>     > Sridhar
> 
>     One concern with promisc mode is that for the common case,
>     which is a single mac and no vlans, we will be getting
>     extra packets that will get dropped in userspace/guest
>     as compared to the case where same mac is programmed
>     in hardware and by guest.
> 
> In the tap/bridge model also, the external i/f is put in promiscuous mode and
> the
> bridge does the filtering of extra packets.

Yes but
1. that is much cheaper than passing them all the way up to the guest.
2. it's pretty painful for management to have to decide between
   features and speed. Better give them both :)

>     We could let userspace supply a list of mac/vlan addresses through
>     an ioctl on macvtap, and then
>     1. for a single mac, program it in hardware
>     2. for other configurations, set promisc mode
> 
>     tun already has TUNSETTXFILTER which might come in handy here.
>     We don't pass in vlans with the filter now but maybe we should.
>     How does this sound?
> 
> I guess this can be done. But i am not sure if we can extend the existing
> TUNSETTXFILTER
> to support vlans too. we may need a new ioctl.
> 
> Thanks
> Sridhar

OK. Maybe add it to tap too.

-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html