From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul Congdon \(UC Davis\)" Subject: Re: [evb] RE: [PATCH][RFC] net/bridge: add basic VEPA support Date: Fri, 7 Aug 2009 14:06:58 -0700 Message-ID: <000001ca17a3$03f841f0$0be8c5d0$@edu> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8492591800840360933==" Cc: arnd@arndb.de, davem@davemloft.net, netdev@vger.kernel.org, bridge@lists.linux-foundation.org, adobriyan@gmail.com, virtualization@lists.linux-foundation.org To: , Return-path: In-Reply-To: Content-Language: en-us List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: bridge-bounces@lists.linux-foundation.org Errors-To: bridge-bounces@lists.linux-foundation.org List-Id: netdev.vger.kernel.org This is a multipart message in MIME format. --===============8492591800840360933== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CA1768.579969F0" Content-Language: en-us 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-- --===============8492591800840360933== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Bridge mailing list Bridge@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/bridge --===============8492591800840360933==--