From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 91CBE37A2 for ; Wed, 8 May 2019 13:15:57 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1D60A24094; Wed, 8 May 2019 07:15:57 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 08 May 2019 07:15:57 -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=HbkcR5Y2zq0S6Vsv92g3bdpoMbhUBW0OR68zwd7SvSI=; b=sEwpD8ZOimsI uSHueCgqFwp0xtlfeweHr3RamnxCygNWvJzxAt5Kb4OTNqfGUbEqIVaPef539S1T ZN68dNNBRm4PhfJQtKHiqaS2k5sqbLnfIlLfkItArqRcmc71wDDggemiMoo5Y333 63doBQvxrQ99590ifVxnNAiHoT9HGos= 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=HbkcR5Y2zq0S6Vsv92g3bdpoMbhUBW0OR68zwd7Sv SI=; b=3VJ0NU/YWJYvQ8ey/C2dpZ5ULdjwebILPTUKu0lRfD8OCaMexdRpjWKoL 6EUYb3FrbPd79l4jfr4DbBEnhC1GEZlnmLlRDd/fu7H6wd01aKnFZHt9/62b3bVM BcucSGJzKgPNGhxeQIDnT8cQlEJGyR18G307DeeUtMG8V1P8SUgFV+YfjIewx3VV g+Ro6eP3EIycW3QDh5MIMqLf/n2RdyMNvOmsH65x5AthpKedKQs+oAG9uCclVMkr +MA7X4mlY41hAGYejhIacXAnMHLu5FEtsLiIOCHKppekPeGNdom63mXFCQjIuxS5 eypi/YggU/Qki1AD399/LnOWuJ1jg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrkeefgdefjecutefuodetggdotefrodftvf 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 4CD5B103D0; Wed, 8 May 2019 07:15:55 -0400 (EDT) From: Thomas Monjalon To: Arnon Warshavsky Cc: dev@dpdk.org, 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: Wed, 08 May 2019 13:15:54 +0200 Message-ID: <2691001.bJ2rVGK9ui@xps> In-Reply-To: <1524552123-31378-1-git-send-email-arnon@qwilt.com> References: <1524552123-31378-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 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: , X-List-Received-Date: Wed, 08 May 2019 11:15:57 -0000 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_eal: int rte_eal_init rte_panic void rte_config_init rte_panic void rte_eal_config_create rte_exit rte_panic void rte_eal_config_attach rte_panic void rte_eal_config_reattach 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 librte_mbuf: void rte_mbuf_sanity_check rte_panic 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 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 82AA9A0096 for ; Wed, 8 May 2019 13:16:00 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0FA1137AF; Wed, 8 May 2019 13:15:59 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 91CBE37A2 for ; Wed, 8 May 2019 13:15:57 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1D60A24094; Wed, 8 May 2019 07:15:57 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 08 May 2019 07:15:57 -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=HbkcR5Y2zq0S6Vsv92g3bdpoMbhUBW0OR68zwd7SvSI=; b=sEwpD8ZOimsI uSHueCgqFwp0xtlfeweHr3RamnxCygNWvJzxAt5Kb4OTNqfGUbEqIVaPef539S1T ZN68dNNBRm4PhfJQtKHiqaS2k5sqbLnfIlLfkItArqRcmc71wDDggemiMoo5Y333 63doBQvxrQ99590ifVxnNAiHoT9HGos= 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=HbkcR5Y2zq0S6Vsv92g3bdpoMbhUBW0OR68zwd7Sv SI=; b=3VJ0NU/YWJYvQ8ey/C2dpZ5ULdjwebILPTUKu0lRfD8OCaMexdRpjWKoL 6EUYb3FrbPd79l4jfr4DbBEnhC1GEZlnmLlRDd/fu7H6wd01aKnFZHt9/62b3bVM BcucSGJzKgPNGhxeQIDnT8cQlEJGyR18G307DeeUtMG8V1P8SUgFV+YfjIewx3VV g+Ro6eP3EIycW3QDh5MIMqLf/n2RdyMNvOmsH65x5AthpKedKQs+oAG9uCclVMkr +MA7X4mlY41hAGYejhIacXAnMHLu5FEtsLiIOCHKppekPeGNdom63mXFCQjIuxS5 eypi/YggU/Qki1AD399/LnOWuJ1jg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrkeefgdefjecutefuodetggdotefrodftvf 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 4CD5B103D0; Wed, 8 May 2019 07:15:55 -0400 (EDT) From: Thomas Monjalon To: Arnon Warshavsky Cc: dev@dpdk.org, 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: Wed, 08 May 2019 13:15:54 +0200 Message-ID: <2691001.bJ2rVGK9ui@xps> In-Reply-To: <1524552123-31378-1-git-send-email-arnon@qwilt.com> References: <1524552123-31378-1-git-send-email-arnon@qwilt.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: <20190508111554.tWr3HEeiBZfUi857FdypkDdLPNNp-8V6xrd1cmsNlHo@z> 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_eal: int rte_eal_init rte_panic void rte_config_init rte_panic void rte_eal_config_create rte_exit rte_panic void rte_eal_config_attach rte_panic void rte_eal_config_reattach 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 librte_mbuf: void rte_mbuf_sanity_check rte_panic 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