linux-kernel - RE: [PATCH][RFC] net/bridge: add basic VEPA support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <0199E0D51A61344794750DC57738F58E6D6B0C7112@GVW1118EXC.americas.hpqcorp.net>
Date:	Thu, 13 Aug 2009 22:24:20 +0000
From:	"Fischer, Anna" <anna.fischer@...com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	"Paul Congdon (UC Davis)" <ptcongdon@...avis.edu>,
	'Stephen Hemminger' <shemminger@...ux-foundation.org>,
	"bridge@...ts.linux-foundation.org" 
	<bridge@...ts.linux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"virtualization@...ts.linux-foundation.org" 
	<virtualization@...ts.linux-foundation.org>,
	"evb@...oogroups.com" <evb@...oogroups.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"kaber@...sh.net" <kaber@...sh.net>,
	"adobriyan@...il.com" <adobriyan@...il.com>,
	'Eric Biederman' <ebiederm@...ssion.com>
Subject: RE: [PATCH][RFC] net/bridge: add basic VEPA support

> 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
> > >
> > > Looking through the discussions here, it does not seem as if a
> decision
> > > was made to integrate those patches, because they would make the
> > > macvlan interface behave too much like a bridge.
> 
> Right, that question is still open, and dont't see it as very important
> right now, as long as we can still use it for VEPA.
> 
> > > Also, it seems as if there was still a problem with doing
> > > multicast/broadcast delivery when enabling local VM-to-VM
> > > communication. Is that solved by now?
> 
> Not yet, but I guess it comes as a natural extension when I fix
> multicast/broadcast delivery from the reflective relay for VEPA.
> 
> The logic that I would use there is:
> 
> broadcast from a dowstream port:
>      if (bridge_mode(source_port)) {
>           forward_to_upstream(frame);
>           for_each_downstream(port) {
>                 /* deliver to all bridge ports except self, do
>                    not deliver to any VEPA port. */
>                 if (bridge_mode(port) && port != source_port) {
>                        forward_to_downstream(frame, port);
>                 }
>           }
>      } else {
>           forward_to_upstream(frame);
>      }
> 
> 
> broadcast from the upstream port
>      if (bridge_mode(frame.source)) {
>           /* comes from a port in bridge mode, so has already been
>              delivered to all other bridge ports */
>           for_each_downstream(port) {
>                 if (!bridge_mode(port)) {
>                          forward_to_downstream(frame, port);
>                 }
>           }
>      } else if (vepa_mode(frame.source)) {
>           /* comes from VEPA port, so need to deliver to all
>              bridge and all vepa ports except self */
>           for_each_downstream(port) {
>                 if (port != frame.source)
>                        forward_to_downstream(frame, port);
>      } else {
>           /* external source, so flood to everyone */
>           for_each_downstream(port) {
>                 forward_to_downstream(frame, port);
>      }
> 
> For multicast, we can do the same, or optionally add a per-port filter
> as you mentioned, if it becomes a bottleneck.
> 
> Do you think this addresses the problem, or did I miss something
> important?

Yes, I think this addresses the problem. It would be very useful if
this functionality was in macvlan.

Thanks,
Anna
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/