Stephen Hemminger wrote:
Or Gerlitz ogerl...@voltaire.com wrote:
Looking in macvlan_set_multicast_list() it acts in a similar manner to
macvlan_set_mac_address() in the sense that it calls dev_mc_sync(). I assume
what's left is to add macvlan_hash_xxx multicast logic to map/unmap
multicast
On Sun, 09 Aug 2009 14:19:08 +0300
Or Gerlitz ogerl...@voltaire.com wrote:
Stephen Hemminger wrote:
I have a patch that forwards all multicast packets, and another that does
proper forwarding. It should have worked that way in original macvlan, the
current behavior is really a bug.
On Friday 07 August 2009, Paul Congdon (UC Davis) wrote:
I don't think your scheme works too well because broadcast packet coming
from other interfaces on br0 would get replicated and sent across the wire
to ethB multiple times.
Right, that won't work. So the bridge patch for the hairpin
On Monday 10 August 2009, Stephen Hemminger wrote:
On Sun, 09 Aug 2009 14:19:08 +0300, Or Gerlitz ogerl...@voltaire.com wrote:
Looking in macvlan_set_multicast_list() it acts in a similar manner to
macvlan_set_mac_address() in the sense that it calls dev_mc_sync(). I
assume what's left is
...@vger.kernel.org ; virtualization@lists.linux-foundation.org ;
e...@yahoogroups.com ; da...@davemloft.net ; ka...@trash.net ;
adobri...@gmail.com ; 'Arnd Bergmann'
Sent: Fri Aug 07 21:58:00 2009
Subject: [evb] RE: [PATCH][RFC] net/bridge: add basic VEPA support
After reading more about this, I am
Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support
On Friday 07 August 2009, Paul Congdon (UC Davis) wrote:
I don't think your scheme works too well because broadcast packet
coming
from other interfaces on br0 would get replicated and sent across the
wire
to ethB multiple
Fischer, Anna anna.fisc...@hp.com writes:
If you do have a SRIOV NIC that supports VEPA, then I would think that
you do not have QEMU or macvtap in the setup any more though. Simply
because in that case the VM can directly access the VF on the physical
device. That would be ideal.
I'm just
Arnd,
I don't think your scheme works too well because broadcast packet coming
from other interfaces on br0 would get replicated and sent across the wire
to ethB multiple times.
Paul
That way you should be able to do something
like:
Host A Host B
/- nalvcam0 -\ /- macvlan0 - 192.168.1.1
Yaron,
The interface multiplexing can be achieved using macvlan driver or using an
SR-IOV capable NIC (the preferred option), macvlan may need to be extended to
support VEPA multicast handling, this looks like a rather simple task
Agreed that the hardware solution is preferred so the macvlan
On Monday 10 August 2009, Fischer, Anna wrote:
On the VEPA filtering service side, the only change we have implemented
in the bridging code is that in VEPA mode all frames are passed to the
uplink on TX. However, frames are still passed through the netfilter
hooks before they go out on the
Subject: Re: [evb] RE: [PATCH][RFC] net/bridge: add basic VEPA support
On Monday 10 August 2009, Stephen Hemminger wrote:
On Sun, 09 Aug 2009 14:19:08 +0300, Or Gerlitz
ogerl...@voltaire.com wrote:
Looking in macvlan_set_multicast_list() it acts in a similar manner
On Mon, 10 Aug 2009 16:32:01 +
Fischer, Anna anna.fisc...@hp.com wrote:
Subject: Re: [evb] RE: [PATCH][RFC] net/bridge: add basic VEPA support
On Monday 10 August 2009, Stephen Hemminger wrote:
On Sun, 09 Aug 2009 14:19:08 +0300, Or Gerlitz
ogerl...@voltaire.com wrote:
Looking
On Monday 10 August 2009, Stephen Hemminger wrote:
On Mon, 10 Aug 2009 16:32:01, Fischer, Anna anna.fisc...@hp.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
Stephen Hemminger wrote:
I have a patch that forwards all multicast packets, and another that does
proper forwarding. It should have worked that way in original macvlan, the
current behavior is really a bug.
Looking in macvlan_set_multicast_list() it acts in a similar manner to
On Saturday 08 August 2009, Benny Amorsen wrote:
Would a SRIOV NIC with VEPA support show up as multiple devices? I.e.
would I get e.g. eth0-eth7 for a NIC with support for 8 virtual
interfaces? Would they have different MAC addresses?
It could, but the idea of SR-IOV is that it shows up as 8
...@gmail.com; a...@arndb.de
Subject: Re: [evb] RE: [PATCH][RFC] net/bridge: add basic VEPA support
Paul,
I also think that bridge may not be the right place for VEPA, but rather a
simpler sw/hw mux
Although the VEPA support may reside in multiple places (I.e. also in the
bridge)
As Arnd pointed
On Fri, 7 Aug 2009 14:06:58 -0700
Paul Congdon \(UC Davis\) ptcong...@ucdavis.edu wrote:
Yaron,
The interface multiplexing can be achieved using macvlan driver or using an
SR-IOV capable NIC (the preferred option), macvlan may need to be extended to
support VEPA multicast handling, this
17 matches
Mail list logo
