DPDK patches and discussions
 help / color / mirror / Atom feed
From: Tyler Retzlaff <roretzla@linux.microsoft.com>
To: David Marchand <david.marchand@redhat.com>
Cc: dev@dpdk.org, thomas@monjalon.net, olivier.matz@6wind.com,
	stephen@networkplumber.org, mb@smartsharesystems.com,
	hofors@lysator.liu.se
Subject: Re: [PATCH v5 1/3] eal: add rte control thread create API
Date: Tue, 7 Feb 2023 13:41:54 -0800	[thread overview]
Message-ID: <20230207214154.GB30628@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> (raw)
In-Reply-To: <CAJFAV8z7etphoJStkzr4-6zwtiDJ=8h3C_UOe1B1=D78UDiOQw@mail.gmail.com>

On Tue, Feb 07, 2023 at 02:12:18PM +0100, David Marchand wrote:
> On Tue, Jan 31, 2023 at 9:30 PM Tyler Retzlaff
> <roretzla@linux.microsoft.com> wrote:
> >
> > Add rte_control_thread_create API as a replacement for
> > rte_ctrl_thread_create to allow deprecation of the use of platform
> > specific types in DPDK public API.
> >
> > Duplicate the rte_ctrl_thread_create test adapted to use
> > rte_control_thread create to keep both APIs under test until
> > rte_ctrl_thread_create is removed.
> >
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > Reviewed-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> > ---
> >  app/test/test_lcores.c             | 41 ++++++++++++++++++
> >  lib/eal/common/eal_common_thread.c | 85 ++++++++++++++++++++++++++++++++++----
> >  lib/eal/include/rte_thread.h       | 33 +++++++++++++++
> >  lib/eal/version.map                |  1 +
> >  4 files changed, 152 insertions(+), 8 deletions(-)
> >
> > diff --git a/app/test/test_lcores.c b/app/test/test_lcores.c
> > index 5b43aa5..9766f78 100644
> > --- a/app/test/test_lcores.c
> > +++ b/app/test/test_lcores.c
> > @@ -353,6 +353,18 @@ static void *ctrl_thread_loop(void *arg)
> >         return NULL;
> >  }
> >
> > +static uint32_t control_thread_loop(void *arg)
> > +{
> > +       struct thread_context *t = arg;
> > +
> > +       printf("Control thread running successfully\n");
> > +
> > +       /* Set the thread state to DONE */
> > +       t->state = Thread_DONE;
> > +
> > +       return 0;
> > +}
> > +
> >  static int
> >  test_ctrl_thread(void)
> >  {
> > @@ -380,6 +392,32 @@ static void *ctrl_thread_loop(void *arg)
> >  }
> >
> >  static int
> > +test_control_thread(void)
> > +{
> > +       struct thread_context ctrl_thread_context;
> > +       struct thread_context *t;
> > +
> > +       /* Create one control thread */
> > +       t = &ctrl_thread_context;
> > +       t->state = Thread_INIT;
> > +       if (rte_control_thread_create(&t->id, "test_control_threads",
> > +                                       NULL, control_thread_loop, t) != 0)
> > +               return -1;
> > +
> > +       /* Wait till the control thread exits.
> > +        * This also acts as the barrier such that the memory operations
> > +        * in control thread are visible to this thread.
> > +        */
> > +       rte_thread_join(t->id, NULL);
> > +
> > +       /* Check if the control thread set the correct state */
> > +       if (t->state != Thread_DONE)
> > +               return -1;
> > +
> > +       return 0;
> > +}
> > +
> > +static int
> >  test_lcores(void)
> >  {
> >         unsigned int eal_threads_count = 0;
> > @@ -409,6 +447,9 @@ static void *ctrl_thread_loop(void *arg)
> >         if (test_ctrl_thread() < 0)
> >                 return TEST_FAILED;
> >
> > +       if (test_control_thread() < 0)
> > +               return TEST_FAILED;
> > +
> >         return TEST_SUCCESS;
> >  }
> >
> 
> Afair, the "legacy" API test being in test_lcores.c is mainly a side
> effect of the API being defined in rte_lcore.h.
> 
> The new API is genuinely located in rte_thread.h and there is no
> consideration over lcores: control thread are just "specialised"
> rte_thread objects.
> I'd rather see this test in app/test/test_threads.c with other
> rte_thread API tests.

no problem, i wondered if i should retain the original location or not.
i'll move it to test_threads.c

i kind of wonder if the function should be named rte_thread_create_ctrl
or something now so that all the functions from rte_thread have a
consistent naming prefix?

let me know if this is desired. if it is i'll submit a new version
otherwise you can apply the series as is with your suggested test moved
to test_threads.c below.

> 
> I think something like below would be enough, wdyt?
> If you are fine with it and there is no other comment on this patch, I
> plan to do this change before applying.

no problem with this, sounds good.

> 
> 
> diff --git a/app/test/test_threads.c b/app/test/test_threads.c
> index e0f18e4329..cc0bb69190 100644
> --- a/app/test/test_threads.c
> +++ b/app/test/test_threads.c
> @@ -232,6 +232,31 @@ test_thread_attributes_priority(void)
>         return 0;
>  }
> 
> +static int
> +test_control_thread_create_join(void)
> +{
> +       rte_thread_t thread_id;
> +       rte_thread_t thread_main_id;
> +
> +       thread_id_ready = 0;
> +       RTE_TEST_ASSERT(rte_control_thread_create(&thread_id,
> "test_control_threads", NULL,
> +               thread_main, &thread_main_id) == 0,
> +               "Failed to create thread.");
> +
> +       while (__atomic_load_n(&thread_id_ready, __ATOMIC_ACQUIRE) == 0)
> +               ;
> +
> +       RTE_TEST_ASSERT(rte_thread_equal(thread_id, thread_main_id) != 0,
> +               "Unexpected thread id.");
> +
> +       __atomic_store_n(&thread_id_ready, 2, __ATOMIC_RELEASE);
> +
> +       RTE_TEST_ASSERT(rte_thread_join(thread_id, NULL) == 0,
> +               "Failed to join thread.");
> +
> +       return 0;
> +}
> +
>  static struct unit_test_suite threads_test_suite = {
>         .suite_name = "threads autotest",
>         .setup = NULL,
> @@ -243,6 +268,7 @@ static struct unit_test_suite threads_test_suite = {
>                 TEST_CASE(test_thread_priority),
>                 TEST_CASE(test_thread_attributes_affinity),
>                 TEST_CASE(test_thread_attributes_priority),
> +               TEST_CASE(test_control_thread_create_join),
>                 TEST_CASES_END()
>         }
>  };
> 
> 
> -- 
> David Marchand

  reply	other threads:[~2023-02-07 21:41 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-05 20:24 [PATCH 0/3] eal: rte_ctrl_thread_create API replacement Tyler Retzlaff
2022-12-05 20:24 ` [PATCH 1/3] eal: add rte control thread create API Tyler Retzlaff
2022-12-05 21:11   ` Stephen Hemminger
2022-12-06  0:21     ` Tyler Retzlaff
2022-12-06 17:35     ` Tyler Retzlaff
2022-12-07  0:49       ` Stephen Hemminger
2022-12-05 20:24 ` [PATCH 2/3] test: add rte control thread create API test Tyler Retzlaff
2022-12-05 20:24 ` [PATCH 3/3] eal: deprecate pthread control thread create API Tyler Retzlaff
2022-12-05 21:18   ` Stephen Hemminger
2022-12-06  0:24     ` Tyler Retzlaff
2022-12-05 20:34 ` [PATCH 0/3] eal: rte_ctrl_thread_create API replacement Morten Brørup
2022-12-06 17:28 ` [PATCH v2 " Tyler Retzlaff
2022-12-06 17:28   ` [PATCH v2 1/3] eal: add rte control thread create API Tyler Retzlaff
2022-12-07  9:13     ` Mattias Rönnblom
2022-12-07 16:38       ` Tyler Retzlaff
2022-12-07 20:37         ` Tyler Retzlaff
2022-12-08 21:59         ` Mattias Rönnblom
2022-12-08 22:15           ` Tyler Retzlaff
2022-12-09  1:09     ` Stephen Hemminger
2022-12-09 19:49       ` Tyler Retzlaff
2022-12-06 17:28   ` [PATCH v2 2/3] test: add rte control thread create API test Tyler Retzlaff
2022-12-06 17:28   ` [PATCH v2 3/3] eal: deprecate pthread control thread create API Tyler Retzlaff
2022-12-07 20:31 ` [PATCH v3 0/3] eal: rte_ctrl_thread_create API replacement Tyler Retzlaff
2022-12-07 20:31   ` [PATCH v3 1/3] eal: add rte control thread create API Tyler Retzlaff
2022-12-07 20:31   ` [PATCH v3 2/3] test: add rte control thread create API test Tyler Retzlaff
2022-12-07 20:31   ` [PATCH v3 3/3] eal: deprecate pthread control thread create API Tyler Retzlaff
2022-12-08 23:19 ` [PATCH v4 0/3] eal: rte_ctrl_thread_create API replacement Tyler Retzlaff
2022-12-08 23:19   ` [PATCH v4 1/3] eal: add rte control thread create API Tyler Retzlaff
2022-12-08 23:19   ` [PATCH v4 2/3] test: add rte control thread create API test Tyler Retzlaff
2022-12-08 23:19   ` [PATCH v4 3/3] eal: deprecate pthread control thread create API Tyler Retzlaff
2022-12-10 14:31   ` [PATCH v4 0/3] eal: rte_ctrl_thread_create API replacement Mattias Rönnblom
2023-01-31 19:46 ` [PATCH v5 0/3] eal: deprecate last use of pthread_t in public API Tyler Retzlaff
2023-01-31 19:46   ` [PATCH v5 1/3] eal: add rte control thread create API Tyler Retzlaff
2023-01-31 19:46   ` [PATCH v5 2/3] doc: add missing index entry for thread Tyler Retzlaff
2023-01-31 19:46   ` [PATCH v5 3/3] doc: announce deprecation of thread ctrl create function Tyler Retzlaff
2023-01-31 20:30 ` [PATCH v5 0/3] eal: deprecate last use of pthread_t in public API Tyler Retzlaff
2023-01-31 20:30   ` [PATCH v5 1/3] eal: add rte control thread create API Tyler Retzlaff
2023-02-07 13:12     ` David Marchand
2023-02-07 21:41       ` Tyler Retzlaff [this message]
2023-01-31 20:30   ` [PATCH v5 2/3] doc: add missing index entry for thread Tyler Retzlaff
2023-02-07 15:39     ` David Marchand
2023-02-07 21:39       ` Tyler Retzlaff
2023-01-31 20:30   ` [PATCH v5 3/3] doc: announce deprecation of thread ctrl create function Tyler Retzlaff
2023-02-07 15:40     ` David Marchand
2023-01-31 20:33   ` [PATCH v5 0/3] eal: deprecate last use of pthread_t in public API Tyler Retzlaff
2023-02-08 21:26 ` [PATCH v6 " Tyler Retzlaff
2023-02-08 21:26   ` [PATCH v6 1/3] eal: add rte thread create control API Tyler Retzlaff
2023-02-24  5:52     ` Li, WeiyuanX
2023-02-24  8:13     ` David Marchand
2023-02-24 19:04       ` Tyler Retzlaff
2023-02-24 20:52       ` Tyler Retzlaff
2023-02-08 21:26   ` [PATCH v6 2/3] doc: add missing index entry for thread Tyler Retzlaff
2023-02-08 21:26   ` [PATCH v6 3/3] doc: announce deprecation of thread ctrl create function Tyler Retzlaff
2023-02-09  8:59     ` Bruce Richardson
2023-02-09  8:51   ` [PATCH v6 0/3] eal: deprecate last use of pthread_t in public API David Marchand
2023-02-09 11:55   ` David Marchand

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=20230207214154.GB30628@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net \
    --to=roretzla@linux.microsoft.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=hofors@lysator.liu.se \
    --cc=mb@smartsharesystems.com \
    --cc=olivier.matz@6wind.com \
    --cc=stephen@networkplumber.org \
    --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).