Description of problem:

The problem affects both Linux and FreeBSD implementations.
When a dpdk control thread is created (interrupt handler thread, multi process thread, vhost reconn thread, etc...), EAL constructs the cpu affinity of the newly created thread by looking at all availables cpu and remove the cpus from the startup corelist/coremask parameter.
The startup cpu affinity list is not taken into account which can have an impact on other performance critical processes running on the system.

How reproducible:
100%

Steps to Reproduce:
1. Start a dpdk application with a restricted cpu affinity list. Example:
taskset -c 0,1,2 testpmd -c 0x3 --no-pci --no-huge -m 512 -- -i --total-num-mbufs 2048


Actual results:
EAL started control threads out of the cpu affinity list:

$ grep -E '(Name|Cpus_allowed_list):' /proc/$(pidof testpmd)/task/*/status
/proc/87677/task/87677/status:Name:	testpmd
/proc/87677/task/87677/status:Cpus_allowed_list:	0
/proc/87677/task/87678/status:Name:	eal-intr-thread
/proc/87677/task/87678/status:Cpus_allowed_list:	2-27
/proc/87677/task/87679/status:Name:	rte_mp_handle
/proc/87677/task/87679/status:Cpus_allowed_list:	2-27
/proc/87677/task/87680/status:Name:	lcore-slave-1
/proc/87677/task/87680/status:Cpus_allowed_list:	1

Expected results:
Control threads should be kept in the initial cpu affinity list, not colliding with "datapath" threads specified via the coremask/corelist EAL parameters.


Additional info:

Bug reported upstream and fixed in commit:
https://git.dpdk.org/dpdk/commit/?id=c3568ea376700df061abcbeabc40ddaed7841e1a