From: Stephen Hemminger <stephen@networkplumber.org>
To: David Vodak <vodak@cesnet.cz>
Cc: Tyler Retzlaff <roretzla@linux.microsoft.com>, dev@dpdk.org
Subject: Re: [PATCH] eal: introduce missing rte_thread wrappers
Date: Wed, 29 Nov 2023 07:52:36 -0800 [thread overview]
Message-ID: <20231129075236.1e0a69a2@hermes.local> (raw)
In-Reply-To: <ee92afd2-eb4a-c287-ba8c-bbd2b0dab12b@cesnet.cz>
On Tue, 28 Nov 2023 09:54:02 +0100
David Vodak <vodak@cesnet.cz> wrote:
> On 11/27/23 18:27, Tyler Retzlaff wrote:
>
> > On Mon, Nov 27, 2023 at 10:25:02AM +0100, David Vodak wrote:
> >> Function rte_ctrl_thread_create has been replaced by rte_thread_create_control,
> >> encouraging Linux users to switch from the pthread_t API to the rte_thread API.
> >> However the rte_thread API does not provide wrappers for all pthread functions.
> >> This commit introduces equivalent functions for pthread_timedjoin_np,
> >> pthread_getname_np and pthread_cancel.
> >>
> >> Bugzilla ID: 1330
> >> ---
> > NAK this series. the rte thread API is not a POSIX emulation API.
> >
> > the point of EAL is not to require applications to have to conditionally
> > compile code around the use of EAL API or handle "not supported"
> > failures it defeats the purpose of being an abstraction library.
> Hi,
>
> I understand that these changes may not be the best alternative. But
> what other options do we have,
> if we are already using functions such as pthread_timedjoin_np? Should
> we just keep using them and
> treat rte_thread_id.opaque_id as pthread_t?
For performance and initial isolated core model, DPDK was initially designed with a specific thread
model using dedicated threads. Over time the thread model has grown a little more
flexible with rte_ctrl threads and service lcores. But DPDK is not a generalized OS
thread model wrapper.
The problem is that DPDK API's need to make some assumptions about being
able to be not preempted and not having locking. If you allow all of pthreads
that will break.
If you want to design an application with a different thread model, then
do not expect the rest of DPDK to work. The burden of support and testing
needs to be shifted back to this application.
prev parent reply other threads:[~2023-11-29 15:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-27 9:25 David Vodak
2023-11-27 17:14 ` Stephen Hemminger
2023-11-27 17:27 ` Tyler Retzlaff
2023-11-28 8:54 ` David Vodak
2023-11-29 15:52 ` Stephen Hemminger [this message]
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=20231129075236.1e0a69a2@hermes.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=roretzla@linux.microsoft.com \
--cc=vodak@cesnet.cz \
/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).