> -----Original Message----- > From: Thomas Monjalon <tho...@monjalon.net> > Sent: Tuesday, September 5, 2023 4:40 PM > To: Van Haaren, Harry <harry.van.haa...@intel.com>; > david.march...@redhat.com; Richardson, Bruce > <bruce.richard...@intel.com>; Andrew Rybchenko > <andrew.rybche...@oktetlabs.ru>; Chaoyong He > <chaoyong...@corigine.com>; Niklas Soderlund > <niklas.soderl...@corigine.com> > Cc: ferruh.yi...@amd.com; dev@dpdk.org; Tyler Retzlaff > <roret...@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
