From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>,
"david.marchand@redhat.com" <david.marchand@redhat.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
Chaoyong He <chaoyong.he@corigine.com>,
Niklas Soderlund <niklas.soderlund@corigine.com>
Cc: "ferruh.yigit@amd.com" <ferruh.yigit@amd.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"Tyler Retzlaff" <roretzla@linux.microsoft.com>,
"Morten Brørup" <mb@smartsharesystems.com>
Subject: RE: drivers use of service cores
Date: Fri, 15 Sep 2023 12:59:07 +0000 [thread overview]
Message-ID: <PH8PR11MB6803D0ABA18C44FABBAAEEA3D7F6A@PH8PR11MB6803.namprd11.prod.outlook.com> (raw)
In-Reply-To: <6541993.tM3a2QDmDi@thomas>
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, September 5, 2023 4:40 PM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>;
> david.marchand@redhat.com; Richardson, Bruce
> <bruce.richardson@intel.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; Chaoyong He
> <chaoyong.he@corigine.com>; Niklas Soderlund
> <niklas.soderlund@corigine.com>
> Cc: ferruh.yigit@amd.com; dev@dpdk.org; Tyler Retzlaff
> <roretzla@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
next prev parent reply other threads:[~2023-09-15 12:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-05 15:40 Thomas Monjalon
2023-09-15 12:59 ` Van Haaren, Harry [this message]
2023-09-15 13:54 ` Morten Brørup
2023-09-15 15:33 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=PH8PR11MB6803D0ABA18C44FABBAAEEA3D7F6A@PH8PR11MB6803.namprd11.prod.outlook.com \
--to=harry.van.haaren@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=bruce.richardson@intel.com \
--cc=chaoyong.he@corigine.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=mb@smartsharesystems.com \
--cc=niklas.soderlund@corigine.com \
--cc=roretzla@linux.microsoft.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).