[lxc-devel] [Fwd: [PATCH 3/4] macvlan: implement bridge, VEPA and private mode]

[Andrian Nord]

Yes, this is very interesting, but in some points it seems to be based
on missing context. May I ask some clarifications about this points?

> MACVLAN_PRIVATE:
>   The device never communicates with any other device
>   on the same upper_dev. This even includes frames
>   coming back from a reflective relay, where supported
>   by the adjacent bridge.

i.e. current behaviour of macvlan?

> MACVLAN_VEPA:
>   The new Virtual Ethernet Port Aggregator (VEPA) mode,
>   we assume that the adjacent bridge returns all frames
>   where both source and destination are local to the
>   macvlan port, i.e. the bridge is set up as a reflective
>   relay.
>   Broadcast frames coming in from the upper_dev get
>   flooded to all macvlan interfaces in VEPA mode.
>   We never deliver any frames locally.

Current macvlan (without possibility of intercommunication or communication
with host's physical device) + possibility of catching broadcasts?

>   interface, but when they come back from a reflective
>   relay, we don't deliver them again.

Hm, I'm completely lost, what is "reflective relay" in link with
"adjacent bridge". This is some feature that should be enabled on
physical device macvlan-device is bound on (and this feature reflects
packets sent to same physical device back to connected macvlan-devices,
allowing intercommunication of macvlans bound on same physical device)?

> [...]
>   Since we know all the MAC addresses, the macvlan bridge
>   mode does not require learning or STP like the bridge
>   module does.

This seems to cover most of common veth uses, and it should be much
faster than veth, right (if we don't need absolutely virtual device)?