From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 4FE125592 for ; Fri, 30 Dec 2016 16:26:23 +0100 (CET) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 45C543B70D for ; Fri, 30 Dec 2016 15:26:22 +0000 (UTC) Received: from dhcp-25-97.bos.redhat.com (unused [10.10.52.171] (may be forged)) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uBUFQLtU031288 for ; Fri, 30 Dec 2016 10:26:21 -0500 From: Aaron Conole To: dev@dpdk.org Date: Fri, 30 Dec 2016 10:25:57 -0500 Message-Id: <1483111580-5397-1-git-send-email-aconole@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 30 Dec 2016 15:26:22 +0000 (UTC) Subject: [dpdk-dev] [RFC 00/23] Refactor eal_init to remove panic() calls 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: Fri, 30 Dec 2016 15:26:23 -0000 In many cases, it's enough to simply let the application know that the call to initialize DPDK has failed. A complete halt can then be decided by the application based on error returned (and the app could even attempt a possible re-attempt after some corrective action by the user or application). There is still some work left in this series. One bit of work left is to take the calls which could reasonably be corrected (and then init can be re-attempted), and make sure to clear the already-initialized flag. Another piece of work is to fix the lcore master/slave errors to properly reflect thread state. Finally, some real heavy testing should be done. The series wasn't tested much, and could use real soak time. Especially around some of the calls where it no longer returns an error (for instance, vdev init and plugin init). Aaron Conole (23): eal: CPU init will no longer panic eal: return error instead of panic for cpu init eal: No panic on hugepages info init eal: do not panic on failed hugepage query eal: failure to parse args returns error eal-common: introduce a way to query cpu support eal: Signal error when CPU isn't supported eal: do not panic on memzone initialization fails eal: set errno when exiting for already called eal: Do not panic on log failures eal: Do not panic on pci-probe eal: do not panic on vfio failure eal: do not panic on memory init eal: do not panic on tailq init eal: do not panic on alarm init eal: convert timer_init not to call panic eal: change the private pipe call to reflect errno eal: Do not panic on interrupt thread init eal: do not error if plugins fail to init eal_pci: Continue probing even on failures eal: do not panic on failed PCI probe eal_common_dev: continue initializing vdevs eal: do not panic (or abort) if vdev init fails lib/librte_eal/common/eal_common_cpuflags.c | 13 ++- lib/librte_eal/common/eal_common_dev.c | 5 +- lib/librte_eal/common/eal_common_lcore.c | 7 +- lib/librte_eal/common/eal_common_pci.c | 15 ++- lib/librte_eal/common/eal_common_tailqs.c | 4 +- .../common/include/generic/rte_cpuflags.h | 9 ++ lib/librte_eal/linuxapp/eal/eal.c | 109 +++++++++++++++------ lib/librte_eal/linuxapp/eal/eal_hugepage_info.c | 6 +- lib/librte_eal/linuxapp/eal/eal_interrupts.c | 5 +- 9 files changed, 125 insertions(+), 48 deletions(-) -- 2.7.4