drivers use of service cores

[Van Haaren, Harry]

> -----Original Message-----
> From: Thomas Monjalon <thomas at monjalon.net>
> Sent: Tuesday, September 5, 2023 4:40 PM
> To: Van Haaren, Harry <harry.van.haaren at intel.com>;
> david.marchand at redhat.com; Richardson, Bruce
> <bruce.richardson at intel.com>; Andrew Rybchenko
> <andrew.rybchenko at oktetlabs.ru>; Chaoyong He
> <chaoyong.he at corigine.com>; Niklas Soderlund
> <niklas.soderlund at corigine.com>
> Cc: ferruh.yigit at amd.com; dev at dpdk.org; Tyler Retzlaff
> <roretzla at linux.microsoft.com>
> Subject: drivers use of service cores
> 
> Hello,

Hi All,

For context, Thomas and I (and a few others) had a brief discussion about this topic
at userspace in Dublin earlier this week.  I have a bit of better understanding of the
problem-space, and we made some progress in technical solutions too.

> I think we can improve the developer experience for using service cores
> from a driver, like finding or allocating a service core.
> We may take some code and ideas from sfc and nfp drivers,
> like in these functions:
> 	nfp_map_service()
> 	sfc_mae_counter_service_register()
> 	sfc_get_service_lcore()
> 
> If it is not possible to use a service core, we could default to using a control thread.
> So the driver would never fail because of a thread initialization.

There was input from a few people that "hidden threads" that their DPDK application
doesn't know about can cause issues (e.g. a driver creating a thread "behind the application's back").
I think Thomas suggested a callback function the application could hook-into, to either accept/decline
the drivers "request" to create a thread.

The default could be "accept" if the application doesn't hook the callback, allowing drivers to default to
achieving work, and allowing power-users to manually handle specific threading-requirements. I have
not strong preference here, just writing down the discussions and feedback from Userspace.

> What do you think about proposing such a high level API
> in order to get more drivers using it?

I believe service-cores was required to transparently enable certain use-cases of HW-acceleration,
Initially Eventdev/SW PMD, but it is of course possible for other components in DPDK to use it.

I do recall some folks had concerns over "scope creep" when initially discussing service-cores upstreaming, and perhaps they're right.
I'm not sure how much more functionality is desired here, vs better usability of the service-cores APIs. Perhaps a POC patch of the
NFP, SFC, etc use-cases would help drive towards a code-level discussion?

Regards, -Harry