>> >> 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
