From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 7 Aug 2009 14:36:52 -0700 From: Stephen Hemminger Message-ID: <20090807143652.1659ac57@nehalam> In-Reply-To: <000001ca17a3$03f841f0$0be8c5d0$@edu> References: <000001ca17a3$03f841f0$0be8c5d0$@edu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Bridge] [evb] RE: [PATCH][RFC] net/bridge: add basic VEPA support List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Paul Congdon (UC Davis)" Cc: arnd@arndb.de, anna.fischer@hp.com, netdev@vger.kernel.org, bridge@lists.linux-foundation.org, davem@davemloft.net, adobriyan@gmail.com, virtualization@lists.linux-foundation.org On Fri, 7 Aug 2009 14:06:58 -0700 "Paul Congdon \(UC Davis\)" wrote: > Yaron, >=20 >=20 > The interface multiplexing can be achieved using macvlan driver or using = an SR-IOV capable NIC (the preferred option), macvlan may need to be extend= ed to support VEPA multicast handling, this looks like a rather simple task= =20 >=20 > Agreed that the hardware solution is preferred so the macvlan implementat= ion doesn=E2=80=99t really matter. If we are talking SR-IOV, then it is di= rect mapped, regardless of whether there is a VEB or VEPA in the hardware b= elow, so you are bypassing the bridge software code also. =20 >=20 > I disagree that adding the multicast handling is simple =E2=80=93 while n= ot conceptually hard, it will basically require you to put an address table= into the macvlan implementation =E2=80=93 if you have that, then why not h= ave just used the one already in the bridge code. If you hook a VEPA up to= a non-hairpin mode external bridge, you get the macvlan capability as well. 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. --=20 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [evb] RE: [PATCH][RFC] net/bridge: add basic VEPA support Date: Fri, 7 Aug 2009 14:36:52 -0700 Message-ID: <20090807143652.1659ac57@nehalam> References: <000001ca17a3$03f841f0$0be8c5d0$@edu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: , , , , , , , To: "Paul Congdon \(UC Davis\)" Return-path: Received: from smtp1.linux-foundation.org ([140.211.169.13]:37127 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752282AbZHGVhZ convert rfc822-to-8bit (ORCPT ); Fri, 7 Aug 2009 17:37:25 -0400 In-Reply-To: <000001ca17a3$03f841f0$0be8c5d0$@edu> Sender: netdev-owner@vger.kernel.org List-ID: On Fri, 7 Aug 2009 14:06:58 -0700 "Paul Congdon \(UC Davis\)" wrote: > Yaron, >=20 >=20 > The interface multiplexing can be achieved using macvlan driver or us= ing an SR-IOV capable NIC (the preferred option), macvlan may need to b= e extended to support VEPA multicast handling, this looks like a rather= simple task=20 >=20 > Agreed that the hardware solution is preferred so the macvlan impleme= ntation doesn=E2=80=99t really matter. If we are talking SR-IOV, then = it is direct mapped, regardless of whether there is a VEB or VEPA in th= e hardware below, so you are bypassing the bridge software code also. =20 >=20 > I disagree that adding the multicast handling is simple =E2=80=93 whi= le not conceptually hard, it will basically require you to put an addre= ss table into the macvlan implementation =E2=80=93 if you have that, th= en why not have just used the one already in the bridge code. If you h= ook a VEPA up to a non-hairpin mode external bridge, you get the macvla= n capability as well. I have a patch that forwards all multicast packets, and another that do= es proper forwarding. It should have worked that way in original macvlan, = the current behavior is really a bug. --=20