On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote: > > This provides the required vxlan bridging function but poses a > scalability problem with using a separate vxlan netdev for each vni.
if I remember correctly this issue was the main reason David Ahern put netdev on diet. Sounds like no more fun at netconf ;) > Solution in this patch series: > The Goal is to use a single vxlan device to carry all vnis similar > to the vxlan collect metadata mode but additionally allowing the bridge > and vxlan driver to carry all the forwarding information and also learn. > This implementation uses the existing dst_metadata infrastructure to map > vlan to a tunnel id. ovs and/or bpf can do the same already, but sounds like the main reason is to keep it integrated with bridge fdb to leverage your offload of bridge fdb into hw asic, right? If so, I guess, the extra complexity can be justified. The question is how do you program hw ? Is there really 1 to 1 mapping in the asics too? Or is it more flexible ? I think most swith asics can do other tunnels too, so can this vlan->vxlan 1 to 1 be generalized to cover different types of tunnels that can be configured on the switch?
