This small series aims to detect when the cpu affinity changes so that
the number of revalidator/handler threads can be adjusted accordingly.
This is specially important on per-cpu dispatch mode.

The only reason for splitting this into two patches is because the first
one can be backported easily while the second is just a small code
cleanup that only makes sense on the master branch.

As a result of these changes (assuming patch 1 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).

We could make old versions as responsive as newer ones but that would
mean moving the thread calculation logic from ofproto layer down to
the dpif (which was done in 2.17 as part of the per-cpu dispatch
feature). This change would be a bit more intrusive to backport.
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.

Adrian Moreno (2):
  ovs-thread: Detect changes in cpu affinity
  ovs-thread: Clean duplicated count_total_cores

 lib/ovs-thread.c | 44 ++++++++++++++++++--------------------------
 1 file changed, 18 insertions(+), 26 deletions(-)

-- 
2.37.2

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to