From: Thomas Monjalon <thomas@monjalon.net>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: Bruce Richardson <bruce.richardson@intel.com>,
David Marchand <david.marchand@redhat.com>, dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] eal/linux: fix return after alarm registration failure
Date: Wed, 26 Jun 2019 15:20:05 +0200 [thread overview]
Message-ID: <3895626.Y0NUr5ymUO@xps> (raw)
In-Reply-To: <f22ddd9f-b1c7-fe45-9c29-a6651f9f47ce@intel.com>
26/06/2019 14:52, Burakov, Anatoly:
> On 26-Jun-19 1:36 PM, Bruce Richardson wrote:
> > On Wed, Jun 26, 2019 at 01:55:53PM +0200, Thomas Monjalon wrote:
> >> 26/06/2019 13:43, Burakov, Anatoly:
> >>> On 26-Jun-19 12:39 PM, David Marchand wrote:
> >>>> On Wed, Jun 26, 2019 at 1:36 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >>>>
> >>>>> 26/06/2019 13:20, David Marchand:
> >>>>>> On Wed, Jun 26, 2019 at 12:41 PM Thomas Monjalon <thomas@monjalon.net>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> When adding an alarm, if an error happen when registering
> >>>>>>> the common alarm callback, it is not considered as a major failure.
> >>>>>>> The alarm is then inserted in the list.
> >>>>>>> However it was returning an error code after inserting the alarm.
> >>>>>>>
> >>>>>>> The error code is reset to 0 so the behaviour and the return code
> >>>>>>> are consistent.
> >>>>>>> Other return code related lines are cleaned up for easier
> >>>>> understanding.
> >>>>>>>
> >>>>> [...]
> >>>>>>> --- a/lib/librte_eal/linux/eal/eal_alarm.c
> >>>>>>> +++ b/lib/librte_eal/linux/eal/eal_alarm.c
> >>>>>>> if (!handler_registered) {
> >>>>>>> - ret |= rte_intr_callback_register(&intr_handle,
> >>>>>>> + ret = rte_intr_callback_register(&intr_handle,
> >>>>>>> eal_alarm_callback, NULL);
> >>>>>>> - handler_registered = (ret == 0) ? 1 : 0;
> >>>>>>> + if (ret == 0)
> >>>>>>> + handler_registered = 1;
> >>>>>>> + else
> >>>>>>> + /* not fatal, callback can be registered later
> >>>>> */
> >>>>>>> + ret = 0;
> >>>>>>> }
> >>>>>>
> >>>>>> Well, then it means that you don't want to touch ret at all.
> >>>>>> How about:
> >>>>>> if (rte_intr_callback_register(&intr_handle,
> >>>>>> eal_alarm_callback, NULL) == 0)
> >>>>>> handler_registered = 1;
> >>>>>>
> >>>>>> ?
> >>>>>
> >>>>> Too much simple :)
> >>>>>
> >>>>> I think we try to avoid calling a function in a "if"
> >>>>> per coding style.
> >>>>> And my proposal has the benefit of offering a comment
> >>>>> about the non-fatal error.
> >>>>>
> >>>>
> >>>> /* not fatal, callback can be registered later */
> >>>> if (rte_intr_callback_register(&intr_handle,
> >>>> eal_alarm_callback, NULL) == 0)
> >>>> handler_registered = 1;
> >>>>
> >>>
> >>> I prefer the original. It's more explicit and conveys the intention
> >>> better. Did i break the tie? :)
> >>
> >> I was going to send a v2 with David's suggestion.
> >> Now I'm confused.
> >>
> > I always tend to prefer shorter versions, so +1 for v2 (does that make it a
> > v3? :-) )
> >
> > /Bruce
> >
>
> OK, but then the suggested comment needs to be fixed. It makes it seem
> like registering the handler is the "non fatal" part. Perhaps something
> like:
>
> /* failed register is not a fatal error - callback can be registered
> later */
Of course! I had prepared this:
/* registration can fail, callback can be registered later */
next prev parent reply other threads:[~2019-06-26 13:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-26 10:40 [dpdk-dev] [PATCH] eal/linux: fix return after alarm registration failure Thomas Monjalon
2019-06-26 11:20 ` David Marchand
2019-06-26 11:36 ` Thomas Monjalon
2019-06-26 11:39 ` David Marchand
2019-06-26 11:43 ` Burakov, Anatoly
2019-06-26 11:55 ` Thomas Monjalon
2019-06-26 12:36 ` Bruce Richardson
2019-06-26 12:52 ` Burakov, Anatoly
2019-06-26 13:20 ` Thomas Monjalon [this message]
2019-06-26 14:02 ` [dpdk-dev] [PATCH v2] " Thomas Monjalon
2019-06-26 23:09 ` Stephen Hemminger
2019-06-27 15:25 ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon
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=3895626.Y0NUr5ymUO@xps \
--to=thomas@monjalon.net \
--cc=anatoly.burakov@intel.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.