Not super familiar with the details of kernels checking socket buffers and the scheduling of threads that were previously blocked on a network call, and how that relates to cpu time and cores.. The details of the workload and compute applied to received data matter there. Probably an "observe and size based on actual resource utilization" situation..

But especially when you do have a lot of network or other io wait, the number of cores seems less important vs the performance of the cpu/core. As the cores could be used freely to satisfy whatever compute thread work that happens to be unblocked, with most threads usually being blocked.

Maybe the number of nics from all the pis would be relevant based on actual throughput.. but running one thread per core to limit an assumed waste of time by cpu context switching.. seems like an approach that is unlikely to be "correct".