Re: [dpdk-dev] Service lcores and Application lcores

["Van Haaren, Harry" <harry.van.haaren@intel.com>]

> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Thursday, June 29, 2017 9:19 PM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>
> Cc: dev@dpdk.org; 'Jerin Jacob' <jerin.jacob@caviumnetworks.com>; Wiles, Keith
> <keith.wiles@intel.com>; Richardson, Bruce <bruce.richardson@intel.com>
> Subject: Re: Service lcores and Application lcores
> 
> 29/06/2017 18:35, Van Haaren, Harry:
> > 3) The problem;
> >    If a service core runs the SW PMD schedule() function (option 2) *AND*
> >    the application lcore runs schedule() func (option 1), the result is that
> >    two threads are concurrently running a multi-thread unsafe function.
> 
> Which function is multi-thread unsafe?

With the current design, the service-callback does not have to be multi-thread safe.
For example, the eventdev SW PMD is not multi-thread safe.

The service library handles serializing access to the service-callback if multiple cores
are mapped to that service. This keeps the atomic complexity in one place, and keeps
services as light-weight to implement as possible.

(We could consider forcing all service-callbacks to be multi-thread safe by using atomics,
but we would not be able to optimize away the atomic cmpset if it is not required. This
feels heavy handed, and would cause useless atomic ops to execute.)


> Why the same function would be run by the service and by the scheduler?

The same function can be run concurrently by the application, and a service core.
The root cause that this could happen is that an application can *think* it is the
only one running threads, but in reality one or more service-cores may be running
in the background.

The service lcores and application lcores existence without knowledge of the others
behavior is the cause of concurrent running of the multi-thread unsafe service function.