From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bruce.richardson@intel.com>
Received: from mga06.intel.com (mga06.intel.com [134.134.136.31])
 by dpdk.org (Postfix) with ESMTP id 61245591E
 for <dev@dpdk.org>; Mon, 27 Feb 2017 13:58:59 +0100 (CET)
Received: from orsmga004.jf.intel.com ([10.7.209.38])
 by orsmga104.jf.intel.com with ESMTP; 27 Feb 2017 04:58:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.35,214,1484035200"; d="scan'208";a="62539427"
Received: from bricha3-mobl3.ger.corp.intel.com ([10.252.1.169])
 by orsmga004.jf.intel.com with SMTP; 27 Feb 2017 04:58:54 -0800
Received: by  (sSMTP sendmail emulation); Mon, 27 Feb 2017 12:58:53 +0000
Date: Mon, 27 Feb 2017 12:58:52 +0000
From: Bruce Richardson <bruce.richardson@intel.com>
To: Aaron Conole <aconole@redhat.com>
Cc: dev@dpdk.org, Stephen Hemminger <stephen@networkplumber.org>
Message-ID: <20170227125852.GA127920@bricha3-MOBL3.ger.corp.intel.com>
References: <20170209142953.8167-1-aconole@redhat.com>
 <20170225160309.31270-1-aconole@redhat.com>
 <20170225160309.31270-3-aconole@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170225160309.31270-3-aconole@redhat.com>
Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?=
 =?iso-8859-1?Q?opment?= Ireland Ltd.
User-Agent: Mutt/1.7.2 (2016-11-26)
Subject: Re: [dpdk-dev] [PATCH v4 02/26] eal: return error instead of panic
	for cpu init
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Feb 2017 12:58:59 -0000

On Sat, Feb 25, 2017 at 11:02:45AM -0500, Aaron Conole wrote:
> There may be no way to gracefully recover, but the application
> should be notified that a failure happened, rather than completely
> aborting.  This allows the user to proceed with a "slow-path" type
> solution.
> 
> Signed-off-by: Aaron Conole <aconole@redhat.com>
> ---
>  lib/librte_eal/linuxapp/eal/eal.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c
> index bf6b818..5023d0d 100644
> --- a/lib/librte_eal/linuxapp/eal/eal.c
> +++ b/lib/librte_eal/linuxapp/eal/eal.c
> @@ -740,6 +740,12 @@ static int rte_eal_vfio_setup(void)
>  }
>  #endif
>  
> +static void rte_eal_init_alert(const char *msg)
> +{
> +    fprintf(stderr, "EAL: FATAL: %s\n", msg);
> +    RTE_LOG(ERR, EAL, "%s\n", msg);
> +}
> +
>  /* Launch threads, called at application init(). */
>  int
>  rte_eal_init(int argc, char **argv)
> @@ -767,8 +773,11 @@ rte_eal_init(int argc, char **argv)
>  	/* set log level as early as possible */
>  	rte_set_log_level(internal_config.log_level);
>  
> -	if (rte_eal_cpu_init() < 0)
> -		rte_panic("Cannot detect lcores\n");
> +	if (rte_eal_cpu_init() < 0) {
> +		rte_eal_init_alert("Cannot detect lcores.");
> +		rte_errno = ENOTSUP;
> +		return -1;
> +	}
>  
>  	fctret = eal_parse_args(argc, argv);
>  	if (fctret < 0)
> -- 
eal.c needs to include rte_errno.h after this change, otherwise it won't
compile.

/Bruce