From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6F7BCA046B for ; Wed, 26 Jun 2019 17:08:18 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8003F25D9; Wed, 26 Jun 2019 17:08:17 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id DD55DF04 for ; Wed, 26 Jun 2019 17:08:16 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 40B7421540; Wed, 26 Jun 2019 11:08:16 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 26 Jun 2019 11:08:16 -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=tYKzDU2mgM6P5mEaMjf2Cyz9WOpyk6K9d1/xpdps4mM=; b=Y58kGyTxEUMy U4bMTs294wswh6XmeiE9xQnukDmgF2SPWv2Y1QHn7OWtGpTN7jKm+4Y0GylonARC /I7fN0PLfHOon2RxeRS2+5MkaZrJ4V+r/KjrAIWqxkX0qtn3qobP1YLmhWEP/qQ+ 7phW0uJZ6w539ryzlEPvBWSqag3NOSQ= 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=fm3; bh=tYKzDU2mgM6P5mEaMjf2Cyz9WOpyk6K9d1/xpdps4 mM=; b=niC8qNS44uvj58kuLDHEoPWKpD3FsML2S4BELqN6Cowa9AUNu+eINOInH F7XxNitbaNSeS+N5UOQdOsX4mDBlTgDS5iB9+H2jfylVWC3TAIK6i0ai4NYSipMl kFK4RWTgUwnFxSbGOI2D/G15OZHFjhM4MwqgbnryKUJ1HQ2pJ8lZNTpV8fX00BmJ /E1hxNH8DlUVjV+TErGf/EKLaqYITsZYYiVu/ZJeT5AYR9g58HVAlE7apyvbd6u0 BAzKxESuVD2tsuVBUYpYErxFGqR43MgshLlHIX5RmVTU1R97rDvLARVsUwdJpNXP GBo4jAYScV5pKep7LYchxikwT0rhQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeigdekiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd 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 760E780064; Wed, 26 Jun 2019 11:08:14 -0400 (EDT) From: Thomas Monjalon To: Arnon Warshavsky Cc: dev@dpdk.org, David Marchand , Stephen Hemminger , Bruce Richardson Date: Wed, 26 Jun 2019 17:08:12 +0200 Message-ID: <5104616.zVJv5nrebN@xps> In-Reply-To: References: <1559661921-8821-1-git-send-email-arnon@qwilt.com> <1560150509-22146-1-git-send-email-arnon@qwilt.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v5] eal: do not panic on shared memory init 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" 11/06/2019 10:07, David Marchand: > On Mon, Jun 10, 2019 at 9:09 AM Arnon Warshavsky wrote: > > > This patch changes some void functions to return a value, > > so that the init sequence may tear down orderly > > instead of calling panic. > > > > Signed-off-by: Arnon Warshavsky > > --- > > > > The calls for launching core messaging threads were left in tact > > in all 3 eal implementations. > > This should be addressed in a different patchset. > > There are still cases where the PMDs or message threads > > may call panic with no context for the user. > > For these I will submit a patch suggesting a callback registration, > > allowing the user to register a context to be called > > in case of a panic that takes place outside the init sequence. > > Reviewed-by: David Marchand > > Thanks Arnon! Applied, thanks For the record, below is the updated status of rte_panic/rte_exit calls in libs: librte_eal: int rte_eal_init rte_panic void eal_thread_init_master rte_panic -> internal change int rte_eal_remote_launch rte_panic -> add a return code eal_thread_loop rte_panic -> abort thread? eal_intr_thread_main rte_panic -> abort thread? int get_hugepage_dir rte_panic -> no public API uint64_t rte_get_timer_cycles uint64_t rte_get_hpet_hz uint64_t rte_get_hpet_cycles rte_panic -> return 0 / no API change librte_mempool: void rte_mempool_* RTE_LIBRTE_MEMPOOL_DEBUG rte_panic -> debug assert librte_mbuf: void rte_mbuf_sanity_check rte_panic -> debug assert librte_lpm: RTE_LIBRTE_LPM_DEBUG VERIFY_DEPTH rte_panic librte_acl: RTE_ACL_VERIFY rte_panic -> debug check? / no API change? librte_sched: void debug_check_queue_slab rte_panic -> debug assert void rte_metrics_init rte_exit -> API breakage librte_kni: struct rte_kni *rte_kni_alloc void kni_fifo_init rte_panic -> no public API change librte_eventdev: struct rte_eventdev *rte_event_pmd_vdev_init rte_panic -> no API change int rte_event_pmd_pci_probe rte_panic -> no API change