From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 6CFF4A0096 for ; Thu, 9 May 2019 15:16:25 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 738463977; Thu, 9 May 2019 15:16:24 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 4C6E7239 for ; Thu, 9 May 2019 15:16:23 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BC93221A7B; Thu, 9 May 2019 09:16:22 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 09 May 2019 09:16:22 -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=qy0QdoGChri/nq9wxpR49N2v47IpzSTi02tczOJdPPg=; b=B3EuxfRXTOJK GSE+98d9T1UQVKv0ybia6OInKc4wx8odEzdCtFt4450qwmvfiEjCDE21+OY9bebw ll8rmv+HfvSd7hiGGrPMLzmMFNWDrxR6Gr1V4x1YbeVoYz6YkKlzL2/rWzyYeVL7 FeM/UuhCjNtZZVtkqO1Vdt4dMQ7x+fg= 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=qy0QdoGChri/nq9wxpR49N2v47IpzSTi02tczOJdP Pg=; b=1MMqUsBWd+Vg/lLr3zREvUdbt5z1RXbERcpbO8SIAT5mLD3rdsta67Uxa 8dW8S85bVB3lHhks7aU3CHuu42OC0psQwRKTpD5gntbRM7t84HpLey3xzK9RL1Ca 5HE7t0WaEOvmfPzV9JsqR78vJMZklIZDYxjLMLxke3sdDCym9G460lG7C3FaWy6W QTX84EW0QhdiV0VMrjlNtpBA9rgHskcL/Wgi/oeogw3S+iF20O6XXvS6C0UkpAsv wUT8k151gi4e/eK4l4ix+jSw0fUb03Y9dksrU5LYrAyFudRGXWP+oIND3VZL4HPp 9rRuAw33WO8TdIP2JnJ27C3J36Pkw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrkeeiucetufdoteggodetrfdotffvucfrrh hofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh ephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgrshcuofho nhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukfhppeejje drudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghs sehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 3D3EF10378; Thu, 9 May 2019 09:16:20 -0400 (EDT) From: Thomas Monjalon To: "Burakov, Anatoly" Cc: Arnon Warshavsky , dev@dpdk.org, 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, 09 May 2019 15:16:18 +0200 Message-ID: <2628728.zknPOL4KMq@xps> In-Reply-To: <232986ad-cd88-4766-ada2-6ec7272dd62a@intel.com> References: <1524552123-31378-1-git-send-email-arnon@qwilt.com> <2691001.bJ2rVGK9ui@xps> <232986ad-cd88-4766-ada2-6ec7272dd62a@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190509131618.AJQh37y7ICPP8b4XLtujmHhEzoDRF3d48Jg8g6UdWb0@z> 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: > > > > > 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).