On 6 Feb 2024, at 14:46, Ilya Maximets wrote:
> On 2/6/24 14:30, Eelco Chaudron wrote: >> Previously, the ability to override the system default for the number >> of handler threads was broken since to the introduction of the per-CPU >> upcall handlers. > > It wasn't broken, it was intentionally disabled. I don't think we should > introduce ability to configure the number of handlers for per-CPU dispatch > mode. It only allows users to shoot themselves in a foot if they do not > understand what they are doing. I think the design was not thought through enough, and resulted in a lot of corner case issues. From the start, we should still have allowed tuning of this option as it was before. > Many integration scripts in a wild are still blindly setting these options > without even knowing that the underlying implementation changed completely. > And those setups may suffer if we suddenly decide to respect the configuration > that is ignored on modern kernels for all currently supported versions of OVS. I feel like this is not OVS’s problem. If people do not know what they are doing, they should not touch it… We have a nice Dutch saying for this "Wie zijn billen brandt, moet op de blaren zitten” :) However, I do feel like we should have an option to configure this, as it makes no sense on a 256-core system to create 256 handler threads. Maybe we should add a new option, n-forced-handler-threads. This will avoid the above issue with existing scripts. Thoughts? //Eelco _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
