Change in libosmocore[master]: vty sched: add api to force deferred applying

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at

pespin gerrit-no-reply at
Tue Sep 14 09:32:26 UTC 2021

pespin has posted comments on this change. ( )

Change subject: vty sched: add api to force deferred applying

Patch Set 2:

(1 comment) 
File src/vty/cpu_sched_vty.c: 
PS2, Line 425: 	if (applynow) {
> All we allow ourselves to do is to apply some changes immediately, and others only at whatever other natural point in time (bts reconnect, etc.), and we document that via attributes.

That's precisely my point here. User configures it and it is expected to be applied at runtime by the app code, for which each thread calls the related function to apply its config. So it's not generic VTY code or the user deciding when to do the mangling with threads at runtime, but rather the app code asking the infra to apply desired thread option at a specific point of time. If one wants to change the usual thread config, it is expected to be applied next time the process is started. If someone really wants to mangle with thread cpu affinity while the process is running, better go do it with linux tools allowing so (they exist) since you anyway should know what you are doing.
So in general when you use this VTY commands, you are configuring where to pin the threads, but when that actually happens is defined by the app itself. You are simply configuring where to allow each thread.

> "enable" style commands don't change persistent configuration.  That's what the configure node and its sub-nodes are for.

I think I wrote there " store it temporarily but not written back to cfg file (have a ->temporary=true)." so I think we agree here? In any case, that's given the event that we really want to use the VTY to apply instantaneous cpu affinity interactively rather than simply configuring it to do so upon startup.

That's my five cents, up to you whether you want to change the state of things here. I'm not for it, but I'm not going to block it. If you want to merge this, then at least provide proper update to the documentation of the cpu affinity section explaining the new behavior and ideas.

To view, visit
To unsubscribe, or for help writing mail filters, visit

Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: Id8405099e6b316c2e14fb0c9b3c5e80a68a91277
Gerrit-Change-Number: 25415
Gerrit-PatchSet: 2
Gerrit-Owner: Hoernchen <ewild at>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge at>
Gerrit-Reviewer: pespin <pespin at>
Gerrit-Comment-Date: Tue, 14 Sep 2021 09:32:26 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: laforge <laforge at>
Comment-In-Reply-To: pespin <pespin at>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gerrit-log mailing list