DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Arnon Warshavsky <arnon@qwilt.com>
Cc: dev@dpdk.org, "Burakov, Anatoly" <anatoly.burakov@intel.com>,
	"Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
	"Doherty, Declan" <declan.doherty@intel.com>,
	Jerin Jacob <jerin.jacob@caviumnetworks.com>,
	Bruce Richardson <bruce.richardson@intel.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	ranjit.menon@intel.com, anand.rawat@intel.com,
	Pallavi Kadam <pallavi.kadam@intel.com>,
	Harini Ramakrishnan <harini.ramakrishnan@microsoft.com>,
	"O'Hare, Cathal" <cathal.ohare@intel.com>
Subject: Re: [dpdk-dev] [PATCH v6 00/11] al: replace calls to rte_panic and refrain from new instances
Date: Sun, 21 Apr 2019 23:10:30 +0200	[thread overview]
Message-ID: <1708848.QKHxId02lC@xps> (raw)
In-Reply-To: <CAKy9EB0cOXCu8K9NiF9-AM8yLcsicmBeML6=HB0RQ87csYDXLw@mail.gmail.com>

21/04/2019 21:16, Arnon Warshavsky:
> Hi,
> I should be able to address this for 19.08, at least the straight forward
> parts.
> I need to touch base again with this patchset later this week,
> to see what changed since then, and see what deprecation notices are
> required.
> I would like to address the ones that are a direct part of the
> initialization sequence,
> and mostly change functions and their callers from void to return a value
> that propagates upwards.
> The 2nd kind under lib that I wanted to remove at the time are the ones
> that live in threads and I would not like to handle them now.
> Given a 3rd kind that is found inside PMDs that may panic during callbacks,
> the former poses a similar challenge of managing the device state after a
> panic event which is not trivial,
> and tmho deserves either a separate patchset or a defeat recognition.
> 
> In this respect , In addition to removing the ones from the initialization
> sequence,
> I would like to revive my original proposal to add a callback registration
> to the panic event.
> As I do not expect all the PMD callback panics to disappear completely,
> I still need to allow the running process to do some kind of orderly
> tear-down to other modules when possible.
> 
> Does this sound ok for 19.08?

That would be great to get some progress in 19.08.
Do not hesitate to split in several patchsets,
getting easy ones first and open discussions other ones.

  parent reply	other threads:[~2019-04-21 21:10 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-24  6:41 Arnon Warshavsky
2018-04-24  6:41 ` [dpdk-dev] [PATCH v6 01/11] crypto/dpaa: replace rte_panic instances in crypto/dpaa driver Arnon Warshavsky
2018-04-24 15:00   ` Stephen Hemminger
2018-04-24 19:27     ` Arnon Warshavsky
2018-04-24  6:41 ` [dpdk-dev] [PATCH v6 02/11] bond: replace rte_panic instances in bonding driver Arnon Warshavsky
2018-04-24  6:41 ` [dpdk-dev] [PATCH v6 03/11] e1000: replace rte_panic instances in e1000 driver Arnon Warshavsky
2018-04-24  6:41 ` [dpdk-dev] [PATCH v6 04/11] ixgbe: replace rte_panic instances in ixgbe driver Arnon Warshavsky
2018-04-24  6:41 ` [dpdk-dev] [PATCH v6 05/11] eal: replace rte_panic instances in eventdev Arnon Warshavsky
2018-04-24 15:04   ` Stephen Hemminger
2018-04-24 15:06   ` Stephen Hemminger
2018-04-24 19:28     ` Arnon Warshavsky
2018-04-24  6:41 ` [dpdk-dev] [PATCH v6 06/11] kni: replace rte_panic instances in kni Arnon Warshavsky
2018-04-24  6:41 ` [dpdk-dev] [PATCH v6 07/11] eal: replace rte_panic instances in hugepage_info Arnon Warshavsky
2018-04-24  6:42 ` [dpdk-dev] [PATCH v6 08/11] eal: replace rte_panic instances in interrupts thread Arnon Warshavsky
2018-04-24  6:42 ` [dpdk-dev] [PATCH v6 09/11] eal: replace rte_panic instances in ethdev Arnon Warshavsky
2018-04-24  6:42 ` [dpdk-dev] [PATCH v6 10/11] eal: replace rte_panic instances in init sequence Arnon Warshavsky
2018-04-24  6:42 ` [dpdk-dev] [PATCH v6 11/11] devtools: prevent new instances of rte_panic and rte_exit Arnon Warshavsky
2018-04-24  6:44 ` [dpdk-dev] [PATCH v6 00/11] al: replace calls to rte_panic and refrain from new instances Arnon Warshavsky
2018-04-24  6:57   ` Arnon Warshavsky
2019-04-18 14:50 ` Thomas Monjalon
2019-04-18 14:50   ` Thomas Monjalon
2019-04-21 19:16   ` Arnon Warshavsky
2019-04-21 19:16     ` Arnon Warshavsky
2019-04-21 21:10     ` Thomas Monjalon [this message]
2019-04-21 21:10       ` Thomas Monjalon
2019-05-08 11:15 ` Thomas Monjalon
2019-05-08 11:15   ` Thomas Monjalon
2019-05-08 14:47   ` David Marchand
2019-05-08 14:47     ` David Marchand
2019-05-09 12:05   ` Burakov, Anatoly
2019-05-09 12:05     ` Burakov, Anatoly
2019-05-09 13:16     ` Thomas Monjalon
2019-05-09 13:16       ` Thomas Monjalon
2019-05-23 11:14       ` Thomas Monjalon
2019-05-23 13:13         ` 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=1708848.QKHxId02lC@xps \
    --to=thomas@monjalon.net \
    --cc=anand.rawat@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=arnon@qwilt.com \
    --cc=bruce.richardson@intel.com \
    --cc=cathal.ohare@intel.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=harini.ramakrishnan@microsoft.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=pallavi.kadam@intel.com \
    --cc=ranjit.menon@intel.com \
    --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).