On 2/1/17, 8:04 PM, Stephen Hemminger wrote: > On Wed, 01 Feb 2017 20:02:35 -0800 > Roopa Prabhu <ro...@cumulusnetworks.com> wrote: > >> On 2/1/17, 5:59 PM, David Ahern wrote: >>> On 2/1/17 6:23 PM, Alexei Starovoitov wrote: >>>> 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 ;) >>>> >>> oh, it still needs a diet ... >> Even if the netdev went on diet, a netdev per vni for vxlan deployments is >> just too much overhead. >> >> > But the intent was VNI == VLAN tag and there are cases where you need per VNI > rules. what rules are these ? > Having them all smashed into one netdev seems like a step in the wrong > direction. only thing that a vxlan netdev per vni carries is a separate fdb table per vni with mac as the key. The natural progression from one fdb table per vni to a single fdb table for all vni's is to support a fdb table with <mac, vni> as the key. So, unclear why it is a step in the wrong direction. This is exactly how the vlan filtering bridge fdb table is built also ...with <mac, vlan> as the key.
And, note that a single vxlan netdev is already deployed in COLLECT_METADATA mode. This series, just makes the fdb available to the single vxlan netdev in COLLECT_METADATA mode. No change to the normal default mode of one vxlan netdev per vni.
