Date: Thu, 19 Dec 2024 08:41:03 -0500 From: Mark Johnston <markj@freebsd.org> To: Zhenlei Huang <zlei@freebsd.org> Cc: freebsd-jail@freebsd.org Subject: Re: setting VNET tunables in a new jail Message-ID: <Z2QibxefYHadYVQ7@nuc> In-Reply-To: <B6C42E20-AFD2-4E82-BCB4-7403177EE999@FreeBSD.org> References: <Z2Hq704UowT2mz2v@nuc> <765C6033-2A81-4CDA-9366-4742F1750421@FreeBSD.org> <Z2L7wJrmGVaoHuzI@nuc> <B6C42E20-AFD2-4E82-BCB4-7403177EE999@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 19, 2024 at 11:07:09AM +0800, Zhenlei Huang wrote: > > > > On Dec 19, 2024, at 12:43 AM, Mark Johnston <markj@freebsd.org> wrote: > > > > On Wed, Dec 18, 2024 at 11:05:46AM +0800, Zhenlei Huang wrote: > >> > >> > >>> On Dec 18, 2024, at 5:19 AM, Mark Johnston <markj@freebsd.org <mailto:markj@freebsd.org>> 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. > >> > >> For current/15, it is actually doable since my previous work [1] and [2]. > >> > >> A usage example is the test plan in https://reviews.freebsd.org/D41825 <https://reviews.freebsd.org/D41825><https://reviews.freebsd.org/D41825 <https://reviews.freebsd.org/D41825>>; . > >> > >> For short, `kenv some.kenv=foo`, and then create vnet jail, `jail -c xxx persist` . > > > > Oh nice, I didn't know about that. > > > >> Those commits are not MFCed to stable/14 and stable/13, as I'm not satisfied > >> with the implementation. The current implementation is somewhat hacky > >> and I planed to re-work it. > > > > I think it's not quite enough for what I want to do. My main use-case > > is the regression test suite, which I typically run in parallel, so > > there's lots of concurrent jail creation and destruction. Some of those > > jail creation operations may want to set kenv values. Modifying the > > kenv is a global operation, so I can't do that from concurrent test > > runners. > > > >>> 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. > >>> > >>> 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. > >> > >> That is per-jail kenv, quite close to my working copy. > > > > You mean, you have some out-of-tree work in progress? > > Yes. I'll publish it when ready. Recently busy working on SYSINIT stuff. Awesome. Please let me know if I can help review or test. > The idea (per-vnet kenv) came when I was working on vnet tunables feature. > > I have ever mentioned this in D46653 [1], but been ignored. I think you hit this once again :) Oops, I'm sorry Zhenlei, I completely missed that. :( > 1. https://reviews.freebsd.org/D46653 > > > > >>> 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. > >>> > >> > >> Best regards, > >> Zhenlei > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Z2QibxefYHadYVQ7>