Stephen Hemminger wrote:
> Or Gerlitz 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 groups to wh
On Monday 10 August 2009, Stephen Hemminger wrote:
> On Mon, 10 Aug 2009 16:32:01, "Fischer, Anna" 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 in
On Mon, 10 Aug 2009 16:32:01 +
"Fischer, Anna" 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 G
> 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
> wrote:
> > > Looking in macvlan_set_multicast_list() it acts in a similar manner
> to
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
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
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
"Fischer, Anna" 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 trying to under
> 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 eth
er.kernel.org ;
net...@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
>
>
On Monday 10 August 2009, Stephen Hemminger wrote:
> On Sun, 09 Aug 2009 14:19:08 +0300, Or Gerlitz 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_h
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 Sun, 09 Aug 2009 14:19:08 +0300
Or Gerlitz 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.
> >
> Looking in
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
macvlan
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
On Friday 07 August 2009, Fischer, Anna wrote:
> 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.
The
On Fri, 7 Aug 2009 14:06:58 -0700
"Paul Congdon \(UC Davis\)" 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 looks like a
...@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
18 matches
Mail list logo
