From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bilemail1.empirix.com (bilemail1.empirix.com [208.67.76.245]) by dpdk.org (Postfix) with ESMTP id B7AF68D97 for ; Thu, 8 Oct 2015 16:59:03 +0200 (CEST) Received: from BILEMAIL1.empirix.com (10.17.8.30) by bilemail1.empirix.com (10.17.8.30) with Microsoft SMTP Server (TLS) id 15.0.775.38; Thu, 8 Oct 2015 10:58:56 -0400 Received: from BILEMAIL1.empirix.com ([fe80::f9e0:9293:2523:f021]) by bilemail1.empirix.com ([fe80::f9e0:9293:2523:f021%22]) with mapi id 15.00.0775.031; Thu, 8 Oct 2015 10:58:56 -0400 From: "Montorsi, Francesco" To: Thomas Monjalon Thread-Topic: [dpdk-dev] rte_eal_init() alternative? Thread-Index: AdDlfPBIBcvmYGE5S+iOMZ1NcwR9ugAI2wEAAAB5coAHDcC0gA== Date: Thu, 8 Oct 2015 14:58:55 +0000 Message-ID: References: <44e664970fef4bff942eaee5c7eaca67@bilemail1.empirix.com> <20150902125650.GA10364@bricha3-MOBL3> <3003120.8bdQ5bCz5C@xps13> In-Reply-To: <3003120.8bdQ5bCz5C@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.12.50.106] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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: Thu, 08 Oct 2015 14:59:04 -0000 Hi, > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: mercoled=EC 2 settembre 2015 15:10 > To: Montorsi, Francesco > Cc: dev@dpdk.org; Bruce Richardson > Subject: Re: [dpdk-dev] rte_eal_init() alternative? >=20 > 2015-09-02 13:56, Bruce Richardson: > > On Wed, Sep 02, 2015 at 12:49:40PM +0000, Montorsi, Francesco wrote: > > > Hi all, > > > > > > Currently it seems that the only way to initialize EAL is using rte_e= al_init() > function, correct? > > > > > > I have the problem that rte_eal_init() will call rte_panic() whenever > something fails to initialize or in other cases it will call exit(). > > > In my application, I would rather like to attempt DPDK initialization= . If it > fails I don't want to exit. > > > Unfortunately I cannot even copy&paste the rte_eal_init() code into m= y > application (removing rte_panic and exit calls) since it uses a lot of DP= DK > internal private functions. > > > > > > I think that my requirements (avoid abort/exit calls when init fails)= is a > basic requirement... would you accept a patch that adds an alternative > rte_eal_init() function that just returns an error code upon failure, ins= tead of > immediately exiting? > > > > > > Thanks for your hard work! > > > > > > Francesco Montorsi > > > > > I, for one, would welcome such a patch. I think the code is overly > > quick in many places to panic or exit the app, when an error code would= be > more appropriate. > > Feel free to also look at other libraries in DPDK too, if you like :-) >=20 > 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. To maintain compatibility with existing applications I think that perhaps t= he best would be to have a core initialization function rte_eal_init_raw() = that never calls rte_panic() and returns an error code. Then we can maintai= n compatibility having an rte_eal_init() function that does call rte_panic(= ) if rte_eal_init_raw() fails. Something like the attached patch.=20 Note that the attached patch exposes also a way to skip the argv/argc confi= guration process by directly providing a populated configuration structure.= .. Let me know what you think about it (the patch is just a draft and needs mo= re work). Thanks, Francesco =09