Use all available cores

[markbeierl]

When determining what cores are available, we should use the total number from the system, not from the current process

Addresses #780

[omecproject]

Can one of the admins verify this patch?

[gab-arrobo]

@markbeierl, have you tested the behavior of this PR when deploying multiple UPF instances in the same host?

[markbeierl]

Yes, I have tested it, and repeated tests show my affinity staying at [1-15] instead of increasing with subsequent runs.

[markbeierl]

Although, to note, we have no method of controlling the UPFs affinity when there is more than one on the physical host, so they both fight for processor 0 in that case.

[gab-arrobo]

@sureshmarikkannu, please review this PR. Thanks!

[gab-arrobo]

@markbeierl, you may need to rebase your PR and make the commit(s) appending the -s flag to pass the DCO check

[sureshmarikkannu]

@markbeierl , Sorry for the delayed review. I want to test multiple scenarios to understand the impact of this change and also want to understand the UPF behavior when we deploy multiple instances of UPF.
Please find my observations below,

1. performance tests with single UPF instance: I run TCP/UDP tests with this patch and all looks good, no issues observed.
2. performance tests with multiple UPF instance: I do see that the same core was assigned for both UPF instances (bess worker threads) which impacts the throughput. Also please note that i do see same behavior without this patch as well (which means psutil.Process().cpu_affinity() returns the entire set of CPU's available in the system).

So in summary when we scale the UPF, we need to utilize the core's carefully in order to not intersect with other UPF's.
We need to use specific set of cores per instance (maybe based on the cores allocated for the UPF pod) for allocating the worker threads.

@gab-arrobo, @markbeierl Let me know your thoughts.

[gab-arrobo]

close as explained in #780