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 691FC2E8A for ; Mon, 30 Jan 2017 17:50:26 +0100 (CET) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (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 C4C9580F75; Mon, 30 Jan 2017 16:50:26 +0000 (UTC) Received: from dhcp-25-97.bos.redhat.com (dhcp-25-172.bos.redhat.com [10.18.25.172]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0UGoPdF018477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Jan 2017 11:50:26 -0500 From: Aaron Conole To: Stephen Hemminger Cc: dev@dpdk.org References: <1485529023-5486-1-git-send-email-aconole@redhat.com> <1485529023-5486-8-git-send-email-aconole@redhat.com> <20170127082738.791401e4@xeon-e3> Date: Mon, 30 Jan 2017 11:50:25 -0500 In-Reply-To: <20170127082738.791401e4@xeon-e3> (Stephen Hemminger's message of "Fri, 27 Jan 2017 08:27:38 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 30 Jan 2017 16:50:26 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 07/25] eal: Signal error when CPU isn't supported 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: Mon, 30 Jan 2017 16:50:26 -0000 Stephen Hemminger writes: > On Fri, 27 Jan 2017 09:56:45 -0500 > Aaron Conole wrote: > >> It's now possible to gracefully exit the application, or for >> applications which support non-dpdk datapaths working in concert with >> DPDK datapaths, there no longer is the possibility of exiting for >> unsupported CPUs. >> >> Signed-off-by: Aaron Conole >> --- >> lib/librte_eal/linuxapp/eal/eal.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c >> index 413be16..cd976f5 100644 >> --- a/lib/librte_eal/linuxapp/eal/eal.c >> +++ b/lib/librte_eal/linuxapp/eal/eal.c >> @@ -752,7 +752,10 @@ rte_eal_init(int argc, char **argv) >> char thread_name[RTE_MAX_THREAD_NAME_LEN]; >> >> /* checks if the machine is adequate */ >> - rte_cpu_check_supported(); >> + if (!rte_cpu_is_supported()) { >> + rte_errno = ENOTSUP; >> + return -1; >> + } >> > > I like not having DPDK applications panic. > My concern is that naive user will not know to check rte_errno. Why not put > a high severity error out as well. If logging is not up just use stderr. I'll work in a quick blurt using stderr. Thanks for the review, Stephen! -Aaron