[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200908102118.49253.arnd@arndb.de>
Date: Mon, 10 Aug 2009 21:18:49 +0200
From: Arnd Bergmann <arnd@...db.de>
To: virtualization@...ts.linux-foundation.org
Cc: Stephen Hemminger <shemminger@...ux-foundation.org>,
"Fischer, Anna" <anna.fischer@...com>,
"Paul Congdon \(UC Davis\)" <ptcongdon@...avis.edu>,
"evb@...oogroups.com" <evb@...oogroups.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"bridge@...ts.linux-foundation.org"
<bridge@...ts.linux-foundation.org>,
"adobriyan@...il.com" <adobriyan@...il.com>,
"davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [evb] RE: [PATCH][RFC] net/bridge: add basic VEPA support
On Monday 10 August 2009, Stephen Hemminger wrote:
> On Mon, 10 Aug 2009 16:32:01, "Fischer, Anna" <anna.fischer@...com> wrote:
> > How would this work though, if the OS inside the guest wants to register
> > to a particular multicast address? Is this propagated through the backend
> > drivers to the macvlan/macvtap interface?
>
> Sure filtering is better, but multicast performance with large number
> of guests is really a corner case, not the real performance issue.
Well, right now, qemu does not care at all about this, it essentially
leaves the tun device in ALLMULTI state. I should check whether macvtap
at this stage can receive multicast frames at all, but if it does,
it will get them all ;-).
If we want to implement this with kvm, we would have to start with
the qemu virtio-net implementation, to move the receive filter into
the tap device. With tun/tap that will mean less copying to user
space, with macvtap (after implementing TUNSETTXFILTER) we get already
pretty far because we no longer need to have the external interface
in ALLMULTI state. Once that is in place, we can start thinking about
filtering per virtual device.
Arnd <><
--
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
Powered by blists - more mailing lists