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

Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support

On Monday 10 August 2009, Fischer, Anna wrote:

quoted

quoted

Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support

On Friday 07 August 2009, Paul Congdon (UC Davis) wrote:

quoted

As I understand the macvlan code, it currently doesn't allow two

VMs

quoted

quoted

on the

quoted

same machine to communicate with one another.

There are patches to do that. I think if we add that, there should

be

quoted

quoted

a way to choose the behavior between either bridging between the
guests or VEPA.

If you implement this direct bridging capability between local VMs

for

quoted

macvlan, then would this not break existing applications that

currently

quoted

use it? It would be quite a significant change to how macvlan works
today. I guess, ideally, you would want to have macvlan work in
separate modes, e.g. traditional macvlan, bridging, and VEPA.

Right, that's what I meant with my sentence above. I'm not sure
if we need to differentiate traditional macvlan and VEPA though.
AFAICT, the only difference should be the handling of broadcast
and multicast frames returning from the hairpin turn. Since this
does not happen with a traditional macvlan, we can always send them
to all macvlan ports except the source port.

Yes, if you add a check for the original source port on broadcast/
multicast delivery, then macvlan would be able to function in
basic VEPA mode. 

Maybe it might still be worth preserving the old behaviour, and 
just add an explicit VEPA mode.

 

quoted

quoted

quoted

I could imagine a hairpin mode on the adjacent bridge making this
possible, but the macvlan code would need to be updated to filter
reflected frames so a source did not receive his own packet.

Right, I missed this point so far. I'll follow up with a patch
to do that.

Can you maybe point me to the missing patches for macvlan that you
have mentioned in other emails, and the one you mention above?
E.g. enabling multicast distribution and allowing local bridging etc.
I could not find any of those in the archives. Thanks.

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. 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?

Thanks,
Anna