From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id D0E85A49A for ; Tue, 27 Mar 2018 22:28:12 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2018 13:28:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,368,1517904000"; d="scan'208";a="186508160" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.9.99]) by orsmga004.jf.intel.com with SMTP; 27 Mar 2018 13:28:08 -0700 Received: by (sSMTP sendmail emulation); Tue, 27 Mar 2018 21:28:07 +0100 Date: Tue, 27 Mar 2018 21:28:07 +0100 From: Bruce Richardson To: =?iso-8859-1?Q?Ga=EBtan?= Rivet Cc: Neil Horman , dev@dpdk.org, "Wiles, Keith" Message-ID: <20180327202807.GB16780@bricha3-MOBL.ger.corp.intel.com> References: <20180327114750.GA30585@hmswarspite.think-freely.org> <20180327124000.6n63hpng53tm3bil@bidouze.vm.6wind.com> <20180327182633.GC30585@hmswarspite.think-freely.org> <20180327202040.rd3yixr67c3jbx4p@bidouze.vm.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180327202040.rd3yixr67c3jbx4p@bidouze.vm.6wind.com> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [dpdk-dev] [PATCH v3 10/20] eal/dev: implement device iteration initialization 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: Tue, 27 Mar 2018 20:28:13 -0000 On Tue, Mar 27, 2018 at 10:20:40PM +0200, Gaëtan Rivet wrote: > On Tue, Mar 27, 2018 at 02:26:33PM -0400, Neil Horman wrote: > > On Tue, Mar 27, 2018 at 02:40:00PM +0200, Gaëtan Rivet wrote: > > > On Tue, Mar 27, 2018 at 07:47:50AM -0400, Neil Horman wrote: > > > > On Tue, Mar 27, 2018 at 01:18:34AM +0200, Gaetan Rivet wrote: > > > > > Parse a device description. > > > > > Split this description in their relevant part for each layers. > > > > > No dynamic allocation is performed. > > > > > > > > > > Cc: Neil Horman > > > > > Cc: "Wiles, Keith" > > > > > Signed-off-by: Gaetan Rivet > > > > > --- > > > > > > > > > > This version uses librte_kvargs. > > > > > > > > > > > > > Otherwise, this looks pretty good to me > > > > > > Please look into the librte_kvargs compatibility patch as well (quite > > > short). I'm very unhappy about the logging hack. > > > There is always the solution of setting a function pointer on rte_log > > > with the proper loglevels and so on. > > > Ideally rte_log could be made independent (starting skimming EAL from > > > all the fat), but this is much less trivial. > > > > > just posted about that. I agree with Keith, I don't think you should need that > > patch. RTE_LOG just calls rte_vlog which contains this code: > > > > if (f == NULL) { > > f = default_log_stream; > > if (f == NULL) { > > /* > > * Grab the current value of stderr here, rather than > > * just initializing default_log_stream to stderr. This > > * ensures that we will always use the current value > > * of stderr, even if the application closes and > > * reopens it. > > */ > > f = stderr; > > } > > } > > } > > > > Which I read as saying that the logging library should back off to stderr if its > > not initialized yet. If you've encountered a problem that made you need that > > logging patch, it seems like you should be able to drop it, and we need to fix > > the logging library. Can you elaborate on what you ran into here? > > > > Neil > > Neat. The issue is that rte_log.h is not symlink-ed until librte_eal is > processed. rte_log cannot be included. > Sure it can - just pass -I/path/to/eal as a cflag. /Bruce