[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