DPDK patches and discussions
 help / color / mirror / Atom feed
From: Arnon Warshavsky <arnon@qwilt.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: Thomas Monjalon <thomas@monjalon.net>,
	"Burakov, Anatoly" <anatoly.burakov@intel.com>,
	wenzhuo.lu@intel.com,  declan.doherty@intel.com,
	jerin.jacob@caviumnetworks.com,  ferruh.yigit@intel.com,
	dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v3] eal: replace rte_panic instances to return an error value
Date: Wed, 21 Mar 2018 11:17:32 +0200	[thread overview]
Message-ID: <CAKy9EB0jS7-guPRnQvrhZqaF3hsE9B121CDpYGiOyibe762X1w@mail.gmail.com> (raw)
In-Reply-To: <20180321091153.GA17868@bricha3-MOBL.ger.corp.intel.com>

I'm a fan of such 1:1 baby steps, but I guess I will stick with the flavor
of majority here.
Will shift those to explicit log and return.

On Wed, Mar 21, 2018 at 11:11 AM, Bruce Richardson <
bruce.richardson@intel.com> wrote:

> On Tue, Mar 20, 2018 at 11:53:08PM +0200, Arnon Warshavsky wrote:
> > The purpose of this patch is to cleanup the library code
> > from paths that end up aborting the process,
> > and move to checking error values, in order to allow the running process
> > perform an orderly tear-down or other mitigation of the event.
> >
> > This patch modifies the majority of rte_panic calls under lib and
> drivers,
> > and replaces them with a new variation of rte_panic macro
> > that does not abort and returns an error value
> > that can be propagated up the call stack.
> >
> > - Focus was given to the dpdk initialization path
> > - Some of the panic calls within drivers were left in place where
> >   the call is from within an interrupt or calls that are on the data
> path,
> >   where there is no simple applicative route to propagate
> >   the error to termination.
> >   These should be handled by the driver maintainers.
> >   I would like to define a device health state that can be monitored from
> >   the side,and this will be an independent patch.
> > - No change took place in example and test files
> > - No change took place for debug assertions calling panic
> > - Some previously void functions calling panic where changed
> >   to return a value,with callers modified accordingly.
> >
> > An additional independent patch to devtools/checkpatches.sh
> > will be submitted in order to prevent new additions of calls to rte_panic
> > under lib and drivers.
> >
> > Keep calm and don't panic.
> >
> > ---
> > V2: Fix typos in commit message
> > ---
> > V3: More commit message formatting
> >
> > Signed-off-by: Arnon Warshavsky <arnon@qwilt.com>
> > ---
> >  drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c       |  2 +-
> >  drivers/crypto/dpaa_sec/dpaa_sec.c                |  2 +-
> >  drivers/net/bonding/rte_eth_bond_8023ad.c         | 23 +++++---
> >  drivers/net/bonding/rte_eth_bond_8023ad_private.h |  2 +-
> >  drivers/net/bonding/rte_eth_bond_api.c            | 20 +++++--
> >  drivers/net/bonding/rte_eth_bond_pmd.c            |  5 +-
> >  drivers/net/bonding/rte_eth_bond_private.h        |  2 +-
> >  drivers/net/e1000/e1000_ethdev.h                  |  2 +-
> >  drivers/net/e1000/igb_ethdev.c                    |  3 +-
> >  drivers/net/e1000/igb_pf.c                        | 10 ++--
> >  drivers/net/ixgbe/ixgbe_ethdev.c                  |  3 +-
> >  drivers/net/ixgbe/ixgbe_ethdev.h                  |  2 +-
> >  drivers/net/ixgbe/ixgbe_pf.c                      |  6 +-
> >  lib/librte_eal/bsdapp/eal/eal.c                   | 54
> ++++++++++-------
> >  lib/librte_eal/bsdapp/eal/eal_debug.c             | 14 +++++
> >  lib/librte_eal/bsdapp/eal/eal_thread.c            | 43 +++++++++-----
> >  lib/librte_eal/common/eal_common_memzone.c        |  2 +-
> >  lib/librte_eal/common/eal_thread.h                |  4 +-
> >  lib/librte_eal/common/include/rte_debug.h         | 20 +++++++
> >  lib/librte_eal/common/rte_malloc.c                |  6 +-
> >  lib/librte_eal/linuxapp/eal/eal.c                 | 72
> ++++++++++++++---------
> >  lib/librte_eal/linuxapp/eal/eal_debug.c           | 14 +++++
> >  lib/librte_eal/linuxapp/eal/eal_hugepage_info.c   | 19 ++++--
> >  lib/librte_eal/linuxapp/eal/eal_interrupts.c      | 16 +++--
> >  lib/librte_eal/linuxapp/eal/eal_thread.c          | 43 +++++++++-----
> >  lib/librte_eal/rte_eal_version.map                |  1 +
> >  lib/librte_ether/rte_ethdev.c                     | 10 +++-
> >  lib/librte_eventdev/rte_eventdev_pmd_pci.h        |  2 +-
> >  lib/librte_eventdev/rte_eventdev_pmd_vdev.h       |  6 +-
> >  lib/librte_kni/rte_kni.c                          | 18 ++++--
> >  lib/librte_kni/rte_kni_fifo.h                     |  6 +-
> >  31 files changed, 291 insertions(+), 141 deletions(-)
> >
> > diff --git a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
> b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
> > index 9a790dd..9fda47c 100644
> > --- a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
> > +++ b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
> > @@ -2865,7 +2865,7 @@ struct rte_security_ops dpaa2_sec_security_ops = {
> >                                       rte_socket_id());
> >
> >               if (cryptodev->data->dev_private == NULL)
> > -                     rte_panic("Cannot allocate memzone for private "
> > +                     rte_panic_return("Cannot allocate memzone for
> private "
> >                                       "device data");
> >       }
>
> To echo Thomas' previous comment, I'm not sure I like the addition of this
> new "panic_return" macro. It seems an artificial hack just to have a 1:1
> replacement for rte_panic. I think I'd rather an explicit log and then
> return call.
>
> /Bruce
>



-- 

*Arnon Warshavsky*
*Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon@qwilt.com
<arnon@qwilt.com>*

  reply	other threads:[~2018-03-21  9:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-20 21:53 Arnon Warshavsky
2018-03-21  9:11 ` Bruce Richardson
2018-03-21  9:17   ` Arnon Warshavsky [this message]
2018-03-27 14:06     ` Arnon Warshavsky

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=CAKy9EB0jS7-guPRnQvrhZqaF3hsE9B121CDpYGiOyibe762X1w@mail.gmail.com \
    --to=arnon@qwilt.com \
    --cc=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=thomas@monjalon.net \
    --cc=wenzhuo.lu@intel.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).