[dpdk-dev] [PATCH v8 04/10] eal: implement functions for thread affinity management

Dmitry Kozlyuk dmitry.kozliuk at gmail.com
Wed Jun 9 01:04:01 CEST 2021


2021-06-04 16:38 (UTC-0700), Narcisa Ana Maria Vasile:
[...]
> +static int
> +rte_convert_cpuset_to_affinity(const rte_cpuset_t *cpuset,
> +			       PGROUP_AFFINITY affinity)
> +{
> +	int ret = 0;
> +	PGROUP_AFFINITY cpu_affinity = NULL;
> +
> +	memset(affinity, 0, sizeof(GROUP_AFFINITY));
> +	affinity->Group = (USHORT)-1;
> +
> +	/* Check that all cpus of the set belong to the same processor group and
> +	 * accumulate thread affinity to be applied.
> +	 */
> +	for (unsigned int cpu_idx = 0; cpu_idx < CPU_SETSIZE; cpu_idx++) {
> +		if (!CPU_ISSET(cpu_idx, cpuset))
> +			continue;
> +
> +		cpu_affinity = eal_get_cpu_affinity(cpu_idx);
> +
> +		if (affinity->Group == (USHORT)-1) {
> +			affinity->Group = cpu_affinity->Group;
> +		} else if (affinity->Group != cpu_affinity->Group) {
> +			ret = EINVAL;
> +			goto cleanup;
> +		}
> +
> +		affinity->Mask |= cpu_affinity->Mask;
> +	}

For v5 I asked a question that possibly got lost among other comments.
Repeating it here for convenience:

	Just to be clear: is it a kernel limitation that a thread can only
	run on cores of one processor group, or do we impose it so that API
	is atomic (transactional), i.e. because one of multiple
	SetThreadGroupAffinity() calls may fail and leave thread partially
	affinitized?


More information about the dev mailing list