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
Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support
On Tuesday 11 August 2009, Paul Congdon (UC Davis) wrote:
The patch from Eric Biederman to allow macvlan to bridge between
its slave ports is at
http://kerneltrap.org/mailarchive/linux-netdev/2009/3/9/5125774
On Tuesday 11 August 2009, Paul Congdon (UC Davis) wrote:
The patch from Eric Biederman to allow macvlan to bridge between
its slave ports is at
http://kerneltrap.org/mailarchive/linux-netdev/2009/3/9/5125774
Looking through the discussions here, it does not seem as if a
Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support
On Tuesday 11 August 2009, Paul Congdon (UC Davis) wrote:
The patch from Eric Biederman to allow macvlan to bridge between
its slave ports is at
http://kerneltrap.org/mailarchive/linux-netdev/2009/3/9/5125774
Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support
On Monday 10 August 2009, Fischer, Anna wrote:
Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support
On Friday 07 August 2009, Paul Congdon (UC Davis) wrote:
As I understand the macvlan code, it currently doesn't
The patch from Eric Biederman to allow macvlan to bridge between
its slave ports is at
http://kerneltrap.org/mailarchive/linux-netdev/2009/3/9/5125774
Looking through the discussions here, it does not seem as if a decision
was made to integrate those patches, because they would make
Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support
On Friday 07 August 2009, Paul Congdon (UC Davis) wrote:
As I understand the macvlan code, it currently doesn't allow two VMs
on the
same machine to communicate with one another.
There are patches to do that. I think if we
On Monday 10 August 2009, Fischer, Anna wrote:
Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support
On Friday 07 August 2009, Paul Congdon (UC Davis) wrote:
As I understand the macvlan code, it currently doesn't allow two VMs
on the
same machine to communicate with one
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
After reading more about this, I am not convinced this should be part
of the bridge code. The bridge code really consists of two parts:
forwarding table and optional spanning tree. Well the VEPA code short
circuits both of these; it can't imagine it working with STP turned
on. The only
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
On Friday 07 August 2009, Paul Congdon (UC Davis) wrote:
As I understand the macvlan code, it currently doesn't allow two VMs on the
same machine to communicate with one another.
There are patches to do that. I think if we add that, there should be
a way to choose the behavior between either
On Friday 07 August 2009, Stephen Hemminger wrote:
So instead of adding more stuff to existing bridge code, why not
have a new driver for just VEPA. You could
do it with a simple version of macvlan type driver.
The current macvlan driver already does the downstream side of
VEPA and only needs
...@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
On Mon, 15 Jun 2009 17:33:10 +
Fischer, Anna anna.fisc...@hp.com wrote:
This patch adds basic Virtual Ethernet Port Aggregator (VEPA)
capabilities to the Linux kernel Ethernet bridging code.
A Virtual Ethernet Port Aggregator (VEPA) is a capability within
a physical end station that
This patch adds basic Virtual Ethernet Port Aggregator (VEPA)
capabilities to the Linux kernel Ethernet bridging code.
A Virtual Ethernet Port Aggregator (VEPA) is a capability within
a physical end station that collaborates with an adjacent, external
bridge to provide distributed bridging
29 matches
Mail list logo