From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 32D9D5952 for ; Thu, 3 Sep 2015 00:02:37 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 02 Sep 2015 15:02:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,456,1437462000"; d="scan'208";a="554120411" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by FMSMGA003.fm.intel.com with ESMTP; 02 Sep 2015 15:02:35 -0700 Received: from orsmsx115.amr.corp.intel.com (10.22.240.11) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 2 Sep 2015 15:02:19 -0700 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by ORSMSX115.amr.corp.intel.com (10.22.240.11) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 2 Sep 2015 15:02:00 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.247]) by fmsmsx111.amr.corp.intel.com ([169.254.12.103]) with mapi id 14.03.0224.002; Wed, 2 Sep 2015 15:01:55 -0700 From: "Wiles, Keith" To: Thomas Monjalon , Don Provan Thread-Topic: [dpdk-dev] rte_eal_init() alternative? Thread-Index: AdDlfPBIBcvmYGE5S+iOMZ1NcwR9ugAPJFUAAAB5coAACrsHAAABgE2AAAR5wAD//7sDgA== Date: Wed, 2 Sep 2015 22:01:54 +0000 Message-ID: References: <44e664970fef4bff942eaee5c7eaca67@bilemail1.empirix.com> <20150902120039.69e3809c@urahara> <1964148.0REVA6fuqc@xps13> In-Reply-To: <1964148.0REVA6fuqc@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.182.147] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0BA0BB29ECB3CD4C8DF8EC9E4BD2CE46@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] rte_eal_init() alternative? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 22:02:38 -0000 On 9/2/15, 4:08 PM, "dev on behalf of Thomas Monjalon" wrote: >2015-09-02 12:00, Stephen Hemminger: >> On Wed, 2 Sep 2015 18:17:40 +0000 >> Don Provan wrote: >>=20 >> > Thomas Monjalon: >> > >Yes but please, do not create an alternative init function. >> > >We just need to replace panic/exit with error codes and be sure that >>apps and examples handle them correctly. >> >=20 >> > I understand your concerns, but the panics are really just the tip of >>the iceberg of the EAL library not realizing it's a library. It really >>makes no sense to think the library should define the application's >>command line, or that the PCI bus should be probed without considering >>whether this application is going to use PCI, and or to insist that EAL >>work be done on internal EAL threads. >> >=20 >> > So I'd say it's way past time to consider revamping initialization to >>start the process of ending the DPDK library's tail wagging the >>application's dog. Naturally this would have to be done while retaining >>the existing init routine on top of a real library initialization, but >>that's just an unfortunate artifact of the library's history, not a >>rational design decision for moving forward. >> >=20 >> > -don provan >> >=20 >>=20 >> You are welcome to submit patches with what you are proposing for >>review. >> Theoretical requirements discussions will probably only result in more >>mail, >> not new code. You know what you want, propose a solution. > >+1 >Everybody agree that DPDK should be more flexible. >We move from a bare metal framework to a real library. >They are shortcuts in original design which can be changed. +1 I was also asked at one point, at DPDK summit was, if a structure based init routine would be better for applications. Instead of passing in command line argvs he wanted to setup a structure in his application to be passed into a new API. The old argvs rte_eal_init() would setup a structure and call into the new rte_eal_struct_init() routine (I guess). I could see the new API would return ERROR (plus errno) to the application if called directly or return ERROR to rte_eal_init() to be handle from the command line. That stated I am not a big fan of huge structures being passed into a init routine as that structure would need to be versioned and it will grow/change. Plus he did not really want to deal in strings, so the structure would be binary values and strings as required. He also wanted DPDK to be more dynamic, meaning some of the values we have in the config files should be more dynamic set via the structure and possible have APIs to enable/disable or set the values. Each config option would have to be looked at IMO, as some are not very easy to be dynamic and maybe not reasonable at all. I believe looking at the current problem of not doing a exit/panic is the first step, next step, if everyone wants, is to look at how to initialize DPDK from an application perspective as compared to a command line one. > >> As far as the command line. That is easily managed by realizing the >>application >> doesn't have to pass the original command line into EAL. If you just >>view the >> command line as a way to pass unstructured options; the application or >>infrastructure >> can build up new values and pass it in. >>=20 >> I agree that initialization itself should try and not fail except in the >> most extreme cases. "ie I can't find /sys what is wrong" and should try >> and adapt more "you asked for 128 cpu's but I see only 2, log it and >>continue" >>=20 > > > =8B=20 Regards, ++Keith Intel Corporation