From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul Congdon \(UC Davis\)" References: In-Reply-To: Date: Fri, 7 Aug 2009 14:06:58 -0700 Message-ID: <000001ca17a3$03f841f0$0be8c5d0$@edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CA1768.579969F0" Content-Language: en-us 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: shemminger@linux-foundation.org, anna.fischer@hp.com Cc: arnd@arndb.de, davem@davemloft.net, netdev@vger.kernel.org, bridge@lists.linux-foundation.org, adobriyan@gmail.com, virtualization@lists.linux-foundation.org This is a multipart message in MIME format. ------=_NextPart_000_0001_01CA1768.579969F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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=20 Agreed that the hardware solution is preferred so the macvlan = implementation 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 the hardware below, so you are bypassing the bridge software code = also. =20 I disagree that adding the multicast handling is simple =E2=80=93 while = not 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 have 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. It also seems to me like the special macvlan interfaces for KVM = don=E2=80=99t apply to XEN or a non-virtualized environment? Or more = has to be written to make that work? If it is in the bridge code, you = get all of this re-use. =20 =20 ------=_NextPart_000_0001_01CA1768.579969F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

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 implementation = 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 the hardware below, so = you are bypassing the bridge software code also. 

I disagree that adding the multicast handling is simple =E2=80=93 while = not 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 have 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.

It also seems to me like the special macvlan interfaces for KVM = don=E2=80=99t apply to XEN or a non-virtualized environment?=C2=A0 Or more has to be written to = make that work?=C2=A0 If it is in the bridge code, you get all of this = re-use.

 

 

------=_NextPart_000_0001_01CA1768.579969F0--