Description:

If --concurrency option is not specified, set the default number of worker threads based on the cpuset of the process. This means that the amount of worker threads is not controlled by the hardware thread count but instead the cpu allocation.

For example, if Envoy is started in a Docker container like this, only four worker threads are created if --concurrency option is not specified:

$ docker run --cpuset-cpus="0-3" ...

The original behavior was that the number of CPU threads in the system would be used to determine the number of worker threads. This number could be very large for servers with multiple physical CPUs and hyperthreading enabled.

This change has a potentially large performance impact, since it changes the default number of threads assigned to Envoy. However, since the original intent of the default concurrency value was to have the number of worker threads matching to the HW capabilities, after this change the Envoy behavior is probably closer to what is expected. Also, std::thread::hardware_concurrency() docs say that the returned value "should be considered only a hint".

There are no tests yet, because I wanted to have some input whether a change like this would be desirable before finalizing the work. Another potential improvement possibility would be monitoring the process cpuset and changing the amount of worker threads dynamically.

Risk Level: Medium
Testing: manual testing with taskset and docker
Docs Changes: Yes, explained the change of behavior
Release Notes: Yes