Hi Harry,
I have few observations on service core feature implementation.
I believe it is allowed to map/unmap a lcore to service while the service is
running (i.e. not just during initialization stage). Please clarify otherwise.
Assuming yes -
In the 'service_run' function, the code to detect use of atomics seems to
result in allowing the mt-unsafe service to run on multiple cores. Looking at
the following code:
1 const int use_atomics = (service_mt_safe(s) == 0) &&
2 (rte_atomic32_read(&s->num_mapped_cores) > 1);
3 if (use_atomics) {
4 if (!rte_atomic32_cmpset((uint32_t *)&s->execute_lock, 0, 1))
5 return -EBUSY;
6
7 rte_service_runner_do_callback(s, cs, i);
8 rte_atomic32_clear(&s->execute_lock);
9 } else
10 rte_service_runner_do_callback(s, cs, i);
Let us say, on core1, after line 4, 'use_atomics' is set to 0. core1 is running
the service function.
On the control plane let us say 'rte_service_map_lcore_set' is called to map
the service to an additional core, core2.
Now, on core2, after line 4, 'use_atomics' is set to 1. But since core1 did not
take execute_lock, core2 will take the lock and starts running the service
function. This should not be allowed since the service is a mt-unsafe service.
Please let me know if my assessment is correct.
A possible solution is to take the execute_lock all the time.
Thank you,
Honnappa
