On 17 Dec 2024, at 22:19, Mark Johnston wrote: > We have a number of sysctls which are defined as tunables, whose values > cannot be changed after boot. Some of these sysctls, such as net.fibs, > are per-VNET so could in principle be changed at jail creation time. > I'd find it useful to be able to pass a set of tunables to jail_set(2), > so that corresponding VNET jail has tunables set to the specified > values. For instance, it'd be useful in test suites where I want to > exercise the network stack with different VNET sysctl settings, without > having to configure the test runner at boot time. > There are a number of such cases. net.fibs is the obvious example, but there’s also net.inet.ip.fw.default_to_accept and net.pf.default_to_drop.
> I think the implementation would involve passing an environment to > vnet_alloc(), which would copy the parent VNET context and then iterate > over all VNET tunables in the system, invoking > sysctl_load_tunable_by_oid_locked() in such a way that the custom > environment is used to update the tunable's value. > > Is there already some way to do what I want? If not, is there some > reason we shouldn't implement this feature? Are there examples of VNET > tunables for which it'd be unsafe to have values differing from the > parent VNET? One can print a list of such variables with "sysctl > -aVNT"; the list is pretty short and I don't see many obvious problems > with allowing them to be modified. I’m not aware of any where it’d be unsafe. Most of them are tuneables because they’d be annoying to make run-time configurable. (e.g. net.pf.states_hashsize would involve allocating a new hash table and re-hashing existing states into it. It’s possible, but to do it without freezing traffic for an extended period would be difficult.) Stuff like that will just work when set for a new vnet. I like this idea. Best regards, Kristof
