From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f51.google.com (mail-pg0-f51.google.com [74.125.83.51]) by dpdk.org (Postfix) with ESMTP id 49DD8FAF6 for ; Thu, 9 Feb 2017 23:38:17 +0100 (CET) Received: by mail-pg0-f51.google.com with SMTP id 14so4243852pgg.1 for ; Thu, 09 Feb 2017 14:38:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=RgnizdDaNwAtd8cvR5mtIxMd3VkM8UvvZdW/YxfRtCs=; b=HFCDth1AzlLkqGpz9B2Uodi1Jz+K/1mjK89U9mhm2Ap+DXTrLyF9iiGtyJ4XyXdaT4 WR1H3F3Jr2raIdq76L5HItO6FmqMuFz4JN1iF0pI3LkjtkPxTnMUGGRowVcHqc5eFBGm q7I+8m0cYbXBLG6HTWn/NvU58tPjX58YT4woAjJWVYRDExwg2gfKod9tZO4kvNI16pjv Bm9Ktc+qfzcEEE+NwuwtDz/g/Hdb7g/ny1xn/9J7oJZdZjn3wRtFUsZT10hiUDTgrwku wIdquHYUL80iVJrJvnfRLUBG2ar62YJ+2J0urYfvYE8NjaIqx29UEt1BSUZpNezsYsmk 26Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=RgnizdDaNwAtd8cvR5mtIxMd3VkM8UvvZdW/YxfRtCs=; b=K/vMxPDn9VGmGAg3E/CtRPylgWTG8m0xj8ji+wFFRskbn0h9eMx0NfYSXGdSZQacqu rMwBFj6t3zo06yQr43GuOdDZcEvoJV0xvC47+0E864HysjcxQHCD3xf4wsVcMy7RgHZJ /wvCyKBHncpWkmA2hEVUKUhAoC9mKb6hBx5bua92oKnMSoCtcV/JqesEzfuYG0+po2UW +oweFN47qPC+a4phHY5NEc7rJxeUj1oce6/S7PCMWYsk0ldR118jnX5P3Z8vhzmIIf3e Nq7iArUfkRCSSOAyoXiAhk9ZNhjJXSsOmL9xFEvo5HH/H8ayEguC8q7DpoKi7Z2SgqrB Yr/A== X-Gm-Message-State: AMke39kaztDN+2AB+l55rHBoOn9JpVH0PRb6jP0fzuphNSeLCvlk2B88qfk/OwM+eSdvJw== X-Received: by 10.84.135.162 with SMTP id 31mr7120436plj.35.1486679896581; Thu, 09 Feb 2017 14:38:16 -0800 (PST) Received: from xeon-e3 (204-195-18-65.wavecable.com. [204.195.18.65]) by smtp.gmail.com with ESMTPSA id 88sm31415271pfr.41.2017.02.09.14.38.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 09 Feb 2017 14:38:16 -0800 (PST) Date: Thu, 9 Feb 2017 14:38:14 -0800 From: Stephen Hemminger To: Aaron Conole Cc: dev@dpdk.org, Bruce Richardson Message-ID: <20170209143814.595e74f5@xeon-e3> In-Reply-To: <20170209142953.8167-1-aconole@redhat.com> References: <20170208185142.28678-1-aconole@redhat.com> <20170209142953.8167-1-aconole@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3 00/25] linux/eal: Remove most causes of panic on 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: , X-List-Received-Date: Thu, 09 Feb 2017 22:38:17 -0000 On Thu, 9 Feb 2017 09:29:28 -0500 Aaron Conole wrote: > 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). > > Changes ->v2: > - Audited all "RTE_LOG (" calls that were introduced, and converted > to "RTE_LOG(" > - Added some fprintf(stderr, "") lines to indicate errors before logging > is initialized > - Removed assignments to errno. > - Changed patch 14/25 to reflect EFAULT, and document in 25/25 > > Changes ->v3: > - Checkpatch issues in patches 3 (spelling mistake), 9 (issue with leading > spaces), and 19 (braces around single line statement if-condition) > > I kept the rte_errno reflection, since this is control-path code and the > init function returns a sentinel value of -1. > > Aaron Conole (25): > 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 > eal: do not panic when bus probe fails > rte_eal_init: add info about rte_errno codes > > 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 | 3 +- > .../common/include/generic/rte_cpuflags.h | 9 ++ > lib/librte_eal/common/include/rte_eal.h | 27 ++++- > lib/librte_eal/linuxapp/eal/eal.c | 122 +++++++++++++++------ > lib/librte_eal/linuxapp/eal/eal_hugepage_info.c | 6 +- > lib/librte_eal/linuxapp/eal/eal_interrupts.c | 5 +- > 10 files changed, 161 insertions(+), 51 deletions(-) > I worry that some of these early failure messages may never be visible because the logging system has not been initialized. Might be safer to just use fprintf(stderr, ...) or define a new wrapper function.