On Fri, Sep 30, 2022 at 11:31 AM Adrian Moreno <[email protected]> wrote: > > Currently, things like the number of handler and revalidator threads are > calculated based on the number of available CPUs. However, this number > is considered static and only calculated once, hence ignoring events > such as cpus being hotplugged, switched on/off or affinity mask > changing. > > This patch makes the number of cpus be calculated every time it's > needed. > > As a result of these changes (assuming the patch is backported): > - >=2.16: a change in the cpu affinity immediately reflects on > the number of threads. > - < 2.16: a change in the cpu affinity will be reflected on > the number of threads the next time there is a call to > bridge_reconfigure() (e.g: on the next DB change). > > The difference in behavior is because on older versions the thread > number calculation was done on bridge reconfiguration while newer > versions moved this logic down to the dpif layer and is run on > dpif->run() stage. > Considering it has not been a huge problem up to today and that the > cpu change would be reflected sooner or later (e.g the user could > force a recalculation with a simple ovs-vsctl command), I think it > might be OK to leave like that. >
Count_cpu_cores() is called many times per second in the main thread, not just in bridge_reconfigure, but also in type_run. Would this impact the performance of bridge_run? Or are these concerns unjustified? Cheers, M _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
