From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id EA892A05D3 for <public@inbox.dpdk.org>; Thu, 23 May 2019 13:15:05 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C8F514C99; Thu, 23 May 2019 13:15:04 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id CB7C725D9 for <dev@dpdk.org>; Thu, 23 May 2019 13:15:02 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 65085383A8; Thu, 23 May 2019 07:15:02 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 23 May 2019 07:15:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=yvmnN2zfMt+ej1GQ3MlocSQ8CgdpXqUya1wc7R041uk=; b=fdMbSNq5Cw68 CLaX64JE5iGs6zJvooezCkGFMOrrNAM6W5cO25u/Axyhnioga+6kN44Mwkk4PiNt ZPrGM33MyUmkLqLxRcRDSCuBduovrAtlRQl46hSarMheFGb3g5X3XLGWjf4j89xZ DKerTa77zp/VjzqvuDkNY/nym3kT8NU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=yvmnN2zfMt+ej1GQ3MlocSQ8CgdpXqUya1wc7R041 uk=; b=WHNvtbEUl7L67pzttZ9dg6uQkrYrTtympoEBB0cFGvGt9Qdelbj8oICd+ iBFhJoN/ljLPeYbxez5DIt1X1oso2hvOSglTweNYlXrseNfoI+jw/gojRCxPuT2D shQdKhHQ+mdzvsNxe4GQP3DUww0mlCtmYI5c2XxJwPJVap/niVhHpPky/qYatdEO zzwcSFApfPEFdo3M28RZm7kHo31wezHArug3LhW6+9KcYdbiLlTG1aplDZkiR7QT j1Ne0drkJ+inZ8EFnygggeA9nnfzqn3798CyaO5Y1eVJYl2lwofE4kYZwwsg8hOo Z6tjvOgFPiap/NyVvN9349cEg3zjQ== X-ME-Sender: <xms:tYDmXIWz7z98uU3b78OlPITb-57MtwLP7nqLqJ9niGrnxcB7ys9Yuw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddugedgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: <xmx:tYDmXFsbLcsSfP-NjQSFWwa0WB_BXcnVI4p3-03ViKEoPxkiqE35oQ> <xmx:tYDmXFTa0L6RtyzElTy7zRsD0Ov-XDWcowYHXe_thwkFOaCxM8oInA> <xmx:tYDmXJ9hn5BGejZ6OUDSY7dOj1mdh49NZFfmvG6bJAoaS48V0UghkQ> <xmx:toDmXORqVumr3jrhCCX1BPjvPBl6DoMizQTJCOCYxWX6b71Vo8eQhg> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 912D6380088; Thu, 23 May 2019 07:15:00 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: Arnon Warshavsky <arnon@qwilt.com> Cc: dev@dpdk.org, "Burakov, Anatoly" <anatoly.burakov@intel.com>, wenzhuo.lu@intel.com, declan.doherty@intel.com, jerin.jacob@caviumnetworks.com, bruce.richardson@intel.com, ferruh.yigit@intel.com, ranjit.menon@intel.com, pallavi.kadam@intel.com Date: Thu, 23 May 2019 13:14:59 +0200 Message-ID: <173180581.QpUCuptbTy@xps> In-Reply-To: <2628728.zknPOL4KMq@xps> References: <1524552123-31378-1-git-send-email-arnon@qwilt.com> <232986ad-cd88-4766-ada2-6ec7272dd62a@intel.com> <2628728.zknPOL4KMq@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v6 00/11] al: replace calls to rte_panic and refrain from new instances X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> Hi Arnon, Any update about this work? Would be good to merge these patches early in 19.08 release. If you need help or more time for some of the patches, do not hesitate to split the work. We could merge obvious patches first. Thanks 09/05/2019 15:16, Thomas Monjalon: > 09/05/2019 14:05, Burakov, Anatoly: > > On 08-May-19 12:15 PM, Thomas Monjalon wrote: > > > 24/04/2018 08:41, Arnon Warshavsky: > > >> The purpose of this patch series 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 teardown or other mitigation of the event. > > >> > > >> This patch modifies the majority of rte_panic calls > > >> under lib and drivers, and replaces them with a log message > > >> and an error return code according to context, > > >> 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 temination. > > >> These should be handled by the driver maintainers.. > > >> - local void functions with no api were changed to retrun a value > > >> where needed > > >> - No change took place in example and test files > > >> - No change took place for debug assertions calling panic > > > > > > I did a status of rte_panic/rte_exit calls in libs. > > > > > > There are a lot of cleanups to do in EAL. > > > We may apply the same kind of solution for Linux, FreeBSD and Windows. > > > > > > The status is described below in a kind of call tree: > > > > <snip> > > > > > librte_mempool: > > > void rte_mempool_* > > > RTE_LIBRTE_MEMPOOL_DEBUG > > > rte_panic > > > > > > > (and other similar places) > > > > Could an argument not be made that when debugging options are enabled, > > having rte_panic there is actually useful? > > Yes I think we can keep them. > In order to make it clear, we could replace them > with RTE_ASSERT or RTE_VERIFY (which calls rte_panic).