> Is it really reasonable to lock your TLS web transfer to a specific CPU thread? Not sure it actually does make sense.
Only if you want good performance. If you're doing a lot of networking, you want your userland socket servicing pinned to the same CPU that the kernel is using for that socket. Which is easiest to achieve if you cpu pin nic queues and server threads. (If you want really good performance, you might want to skip userland with sendfile + kTLS or nic TLS, or maybe skip the kernel with userland networking)
For a benchmark, cpu pinning and tight control of the system is a clear prerequisite; you want to maximize repeatability, and user threads bouncing around cpu threads leads to less repeatable results.
Only if you want good performance. If you're doing a lot of networking, you want your userland socket servicing pinned to the same CPU that the kernel is using for that socket. Which is easiest to achieve if you cpu pin nic queues and server threads. (If you want really good performance, you might want to skip userland with sendfile + kTLS or nic TLS, or maybe skip the kernel with userland networking)
For a benchmark, cpu pinning and tight control of the system is a clear prerequisite; you want to maximize repeatability, and user threads bouncing around cpu threads leads to less repeatable results.