DPDK patches and discussions
 help / color / mirror / Atom feed
From: Robert Sanford <rsanford2@gmail.com>
To: Olivier MATZ <olivier.matz@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC PATCH] rte_timer: Fix rte_timer_reset return value
Date: Fri, 6 Feb 2015 12:26:30 -0500	[thread overview]
Message-ID: <CA+cr1coAamT1OkL-Ts6gWe+N_fuJf-uQunJeTqUg_ngDGM1Vfg@mail.gmail.com> (raw)
In-Reply-To: <54D4A116.1090402@6wind.com>

Hi Olivier,

Thanks for reviewing this patch.
Please see my responses to your comments, below.

I also have one request for you. You probably use git almost every day. For
people who only use git maybe once per year, could you please show us the
exact sequence of commands that you run to prepare a patch series? We know
there are man pages and online documents, etc, but it would be an extremely
valuable jumpstart if you just give us a snippet of your shell history
showing the exact commands that you run to prepare and email a patch
series. I would much rather spend time getting the code right, and less
time learning (by trial and error) the nuances of git apply, add, commit,
format-patch, send-email, etc.


>       /* now check that we get the right number of callbacks */
> >       if (lcore_id == rte_get_master_lcore()) {
> > +             if ((my_collisions = rte_atomic32_read(&collisions)) != 0)
> > +                     printf("- %d timer reset collisions (OK)\n",
> my_collisions);
>
> That's not very important, but I think avoiding affectation + comparison
> at the same time is clearer:
>
>   my_collisions = rte_atomic32_read(&collisions);
>   if (my_collisions != 0) {
>         ...
>

Yes, I will change this.


> > @@ -311,6 +323,13 @@ timer_stress2_main_loop(__attribute__((unused))
> void *arg)
> >       /* now check that we get the right number of callbacks */
> >       if (lcore_id == rte_get_master_lcore()) {
> >               rte_timer_manage();
> > +
> > +             /* clean up statics, in case we run again */
> > +             rte_free(timers);
> > +             timers = 0;
>
> timers = NULL is better than timers = 0 as it's a pointer.
>

Yes, I will change this.


> > +             ready = 0;
>
> The lines above should go in another patch as it fixes another problem
> (+ a memory leek).
> "testpmd: allow to restart timer stress tests"
>

Yes, I will split it into two patches: rte_timer and test_timer. But, I
don't see much benefit in splitting test_timer.c changes into separate
patches for each bug discovered.


> > diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
> > index 269a992..d18abf5 100644
> > --- a/lib/librte_timer/rte_timer.c
> > +++ b/lib/librte_timer/rte_timer.c
> > @@ -424,10 +424,8 @@ rte_timer_reset(struct rte_timer *tim, uint64_t
> ticks,
> >       else
> >               period = 0;
> >
> > -     __rte_timer_reset(tim,  cur_time + ticks, period, tim_lcore,
> > +     return __rte_timer_reset(tim,  cur_time + ticks, period, tim_lcore,
> >                         fct, arg, 0);
> > -
> > -     return 0;
> >  }
> >
> >  /* loop until rte_timer_reset() succeed */
> > @@ -437,7 +435,8 @@ rte_timer_reset_sync(struct rte_timer *tim, uint64_t
> ticks,
> >                    rte_timer_cb_t fct, void *arg)
> >  {
> >       while (rte_timer_reset(tim, ticks, type, tim_lcore,
> > -                            fct, arg) != 0);
> > +                            fct, arg) != 0)
> > +             rte_pause();
> >  }
>
> Maybe the lines above could go to another patch too.
> "timers: relax cpu in rte_timer_reset_sync()"
>
>
If you mean that we should have one patch for rte_timer_reset() and one for
rte_timer_reset_sync(), my response is: Come on, these are two one-line
fixes in a pair of related and adjacent functions. Let's not go overboard
by splitting them into two patches. :-)

Also, I think the commit log should highlight the fact that
> your patch also fixes rte_timer_reset_sync() that was not
> working at all.
>
>
We said something to that effect: "Change API rte_timer_reset_sync() to
invoke rte_pause() while spin-waiting for rte_timer_reset() to succeed." I
can use different wording if you like.


>
> Thanks!
> Olivier
>

Thank you,
Robert

  reply	other threads:[~2015-02-06 17:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-03 20:42 rsanford2
2015-02-06 11:10 ` Olivier MATZ
2015-02-06 17:26   ` Robert Sanford [this message]
2015-02-08 10:53     ` Olivier MATZ
2015-02-25  4:09 ` [dpdk-dev] [PATCH v2 0/3] timer: fix rte_timer_reset Robert Sanford
2015-02-25  8:58   ` Olivier MATZ
2015-02-25  9:46     ` Thomas Monjalon
2015-02-25 11:02       ` Robert Sanford
2015-02-25 11:09         ` Thomas Monjalon
2015-02-25 11:16         ` Bruce Richardson
2015-02-25 13:34           ` Robert Sanford
2015-02-25  4:09 ` [dpdk-dev] [PATCH v2 1/3] timer: pause in rte_timer_reset_sync Robert Sanford
2015-02-25  4:09 ` [dpdk-dev] [PATCH v2 2/3] timer: fix stress test on multiple runs Robert Sanford
2015-02-25  4:09 ` [dpdk-dev] [PATCH v2 3/3] timer: fix rte_timer_reset return value Robert Sanford

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=CA+cr1coAamT1OkL-Ts6gWe+N_fuJf-uQunJeTqUg_ngDGM1Vfg@mail.gmail.com \
    --to=rsanford2@gmail.com \
    --cc=dev@dpdk.org \
    --cc=olivier.matz@6wind.com \
    /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).