tcp: Create fewer per-VNET zones

[markj]

Summary

We have a problem in UMA where creating new zones requires a traversal
of all existing zones (in order to find a unique name for the vm.uma
sysctl subtree). This means that per-VNET UMA zones can be expensive to
create if one creates many VNET jails in a row. This itself is a
problem, but I don't see a quick solution.

Ideally we would avoid creating per-VNET zones in the first place, and
it turns out that the TCP fastopen and SACK code seems to create several
per-VNET zones. I can't see a reason for this.

So: make fastopen and SACK zones global. Move some fastopen structure
definitions into tcp_fastopen.c, as they don't need to be public.

Note, this means that we don't get any leak checking when a per-VNET
zone is destroyed. That is a minor regression, but probably acceptable?
In the medium term I am hoping to add a general kernel memory leak
detection mechanism.

Reported by: bapt ("creating many VNET jails in a row is slow")

[tuexen]

I think the reason for per VNET zones might have been to protect against the case where a service running in one VNET cannot run the services running in other VNETs out of resources. However, that would require per VNET limits and would need to require that this isolation is done for all resources, which doesn't seem to be the case.

[markj]

In D59708#1370131, @tuexen wrote:

I think the reason for per VNET zones might have been to protect against the case where a service running in one VNET cannot run the services running in other VNETs out of resources. However, that would require per VNET limits and would need to require that this isolation is done for all resources, which doesn't seem to be the case.

Right, that is one legitimate use for per-VNET zones. In the long term, UMA itself should perhaps provide this functionality, rather than forcing consumers to create separate zones.

[tuexen]

In D59708#1370145, @markj wrote:

In D59708#1370131, @tuexen wrote:

I think the reason for per VNET zones might have been to protect against the case where a service running in one VNET cannot run the services running in other VNETs out of resources. However, that would require per VNET limits and would need to require that this isolation is done for all resources, which doesn't seem to be the case.

Right, that is one legitimate use for per-VNET zones. In the long term, UMA itself should perhaps provide this functionality, rather than forcing consumers to create separate zones.

That makes a lot of sense to me.

[glebius]

Thanks a lot! I've been moving in this direction for the last 5 years, but these two zones were missed. The SACK of course is more important. The associated changes like hiding declaration and new name for tcp_destroy are also great.

P.S. While multiple limits in the UMA is a great idea, we actually can have an easier mechanism to limit jails to use memory. If we limit a jail to a certain number of sockets, we effectively limit use of most zones in the network stack.