It probably can be implemented correctly, but I think it would require locking while the hash grows or shrinks. This change tries to strike a balance between the speed of VLAN_ARRAY and the memory savings of using the hash table, while avoiding the complexity associated with growing and shrinking the hash table. Growing and shrinking a hash table that can have a max 4096 entries just seems like overkill.

What is needed to continue moving this forward?

In D48896#1115745, @kp wrote:

I know there are users out there who run a very large number of vlans (>> 256) who might be affected by this. On the other hand, they ought to be using VLAN_ARRAY.

I'm tempted to suggest we should just make VLAN_ARRAY default, because it's not that much memory in the grand scheme of things, and it removes even more complexity.

In D48896#1115702, @glebius wrote:

Haven't yet looked in detail, but have a quick question. Did you try VLAN_ARRAY option? Many years ago we left it in assumption that in some cases a user may want a full array of VLANs. I wonder if it is still functioning, since it was never compiled by default or advertised.