Date: Tue, 17 Dec 2024 22:41:15 +0100 From: Kristof Provost <kp@FreeBSD.org> To: Mark Johnston <markj@freebsd.org> Cc: freebsd-jail@freebsd.org Subject: Re: setting VNET tunables in a new jail Message-ID: <AE2C8BFC-EB90-4906-9219-D2CAF137948B@FreeBSD.org> In-Reply-To: <Z2Hq704UowT2mz2v@nuc> References: <Z2Hq704UowT2mz2v@nuc>
next in thread | previous in thread | raw e-mail | index | archive | help
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 th= ere=E2=80=99s 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=E2=80=99m not aware of any where it=E2=80=99d be unsafe. Most of them a= re tuneables because they=E2=80=99d be annoying to make run-time configur= able. (e.g. net.pf.states_hashsize would involve allocating a new hash ta= ble and re-hashing existing states into it. It=E2=80=99s possible, but to= do it without freezing traffic for an extended period would be difficult= =2E) Stuff like that will just work when set for a new vnet. I like this idea.= Best regards, Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AE2C8BFC-EB90-4906-9219-D2CAF137948B>