We have not tried VLAN_ARRAY, but I'm sure it would be fine. This isn't really about finding a solution for us, since we have this change already in our codebase and it is working fine for us. This is about providing a fix from our codebase to FreeBSD for a bug that we found. Given that this is low priority for you, it seems to make sense to get this fix in, until you can try alternate ideas.

I think it would be good to move forward with this change, since as Gleb said, the resizing function is definitely broken.

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.