>> >> I'd rather we fix the essence of the scalability problem than add >> more spaghetti code to the various bridge paths. >> >> Can we make the fdb entries smaller? >> >> Can we enhance how we store such local entries such that they live in >> a compact datastructure? Perhaps the FDB can consist of a very dense >> lookup mechanism for local stuff sitting alongside the current table. > > Certainly, that should be done and I will look into it, but the essence of this patch > is a bit different. The problem here is not the size of the fdb entries, it’s more the > number of them - having 96000 entries (even if they were 1 byte ones) is just way > too much especially when the fdb hash size is small and static. We could work on making > it dynamic though, but still these type of local entries per vlan per port can easily be avoided > with this option. > I was wondering if it is possible to assign a vlan bitmap for the FDB entry, instead of replicating the entry for each vlan. ( I believe Roopa has done something similar, but not so sure). This means that the number of FDB entries remain static for any number of vlans. I guess its more complicated than it sounds, but just wanted to know if its feasible at all. Thanks Vissu > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html
